Non-nominal runtime behavior on MacOS #120
Comments
|
Hello Monica! Thanks for posting these logs. I suspect that in certain cases, there is an issue with the interoperability between Device Client and the local proxy since these two codebases do not have feature/function parity at the moment. It is very much still a bug, and will keep this issue open as we try to find a short-term fix for it. If you want to make sure that this is indeed the case, please try running the localproxy on both the source and destination side (without device client) to see if the tunnel works. |
|
As a follow up if you still want to use Device Client on the destination, try using the previous version of the local proxy and repeat the steps you took to open your VNC tunnel. Please let me know if you still run into issues. v2.3.1 here: https://github.com/aws-samples/aws-iot-securetunneling-localproxy/releases/tag/v2.3.1 |
|
I'll try both. With device client, and without. I'll reply shortly with my results. |
|
No luck with using localproxy v2.3.1. I didn't really get an error code or error message. When I try to connect to the port, it just hangs for me. I'll try local proxy on both source & destination now... |
|
I'm trying local proxy v2.3.1 on destination. Now I'm getting this: ./localproxy -r us-east-1 -d 5901 -v 6 -t <TOKEN_HERE> 2023-02-01T12:31:36.349070]{3846}[error] Proxy server rejected web socket upgrade request: (HTTP/1.1 400 Bad Request) "Invalid access token: The access token was previously used and can not be used again." I'm getting that even when I regenerated the access tokens. I'm not sure why I'm getting that message, even if I never used the access token before. I'm going to try an updated version of local proxy on destination next. |
|
I'm getting the same behavior on the destination side with the updated version of local proxy. On the source side, I get error_code=1047. |
|
Thanks for testing. So just to confirm when you use the latest local proxy version on the destination side, are you getting the same error as in "invalid access token" or another error you mentioned above? Also was curious to see that you get error code 1047 from the source side as well. Apologies for the inconvenience, we're working on getting a VNC test environment set up on our side so we can better understand where this issue is coming from. |
|
On the destination side with the latest local proxy version, I get the "invalid access token". `./localproxy -r us-east-1 -d 127.0.0.1:5901 -v 6 -t TOKEN_HERE [2023-02-01T15:50:40.204826]{28514}[trace] Web socket upgrade response: Invalid access token: The access token was previously used and can not be used again. On the source side with the latest proxy version, I get the error_code=1047 with the aws-iot-device-client logs. `./localproxy -r us-east-1 -s 5555 -v 6 -t TOKEN_HERE [2023-01-31T13:45:28.188785]{35422}[trace] Web socket upgrade response: [2023-01-31T13:45:28.188942]{35422}[trace] Calling binary with type: websocket_stream_single_ssl_type |
|
I will say though, that this stale access token behavior is a little strange and this is the first time I've heard of such a thing happening. If you want to set the environment variable instead, you can cat from a file like this.
The clientAccessToken is optional and should be locally generated once-per-tunnel using If it is indeed an issue with the service-side validation, I will have to consult with their team. |
|
hmmm....now I'm getting this: X-Status-Reason: client-token must match ^[a-zA-Z0-9-]{32,128}$ client-token must match ^[a-zA-Z0-9-]{32,128}$ |
|
Looks like the token failed the regex check, make sure there are no special characters, spaces, and remove any newlines at the end of the file. Example of a generated unique id: |
|
You can generate a valid uuid with the linux command |
|
I added up installing the local proxy (source) on Ubuntu, instead of Mac. I was able to setup the ssh & vnc connection to the remote/destination device (Ubuntu too). Seems like local proxy does not work very well with Mac as the source. |
|
Thank you for the insights, renaming this issue to more closely reflect the nature of the problem... |
Describe the bug
I'm running this on my laptop - trying to do a VNC tunnel on a remote Ubuntu device.
./localproxy -r us-east-1 -s 8000 -v 6 -t TOKEN_HEREI am getting this from localproxy:
Handling tcp socket error for service id: VNC connection id: 1. error message: End of fileAnd, I'm getting this from aws-iot-device-client logs:
TcpForward::OnConnectionResult error_code=1047To Reproduce
Steps to reproduce the behavior:
VNC is running on the remote Ubuntu device already.
Creating tunnel first...
aws iotsecuretunneling open-tunnel --cli-input-json file:///X/tunnel.json --region us-east-1Running local proxy on my laptop...
./localproxy -r us-east-1 -s 8000 -v 6 -t TOKEN_HEREExpected behavior
A working VNC tunnel.
Actual behavior
No VNC tunnel. :(
Logs
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: