Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

message format / encryption problem? #4

Open
TonyApuzzo opened this issue Dec 13, 2017 · 4 comments
Open

message format / encryption problem? #4

TonyApuzzo opened this issue Dec 13, 2017 · 4 comments

Comments

@TonyApuzzo
Copy link

TonyApuzzo commented Dec 13, 2017

Hi, I'm seeing a strange issue in that the loginMessage seems corrupt or maybe encrypted. It is showing up as type Buffer instead of string. I've tried decoding it using utf-8, ucs2, and base64 with no luck. I added a bit of logging to my fork. Is it possible that vesync is using TLS now? I don't know what magic # to use to figure that out. The Buffer starts with "ab d7 39 97 ef ..." rather than a nice JSON payload. Maybe this is an issue of versioning? I had to change some versions to get it to run (pushed to my fork and branch). I put a npm-shrinkwrap in my fork to maybe help with debugging?

I also have a Dockerfile to simplify things (it automatically looks up the hostname directly to 8.8.8.8 and puts it into /etc/hosts).

I've tried this with bare-metal and Docker and get the same errors.

My fork is here branch feature/docker

To run in Docker, arrange to have your docker host be the DNS resolution for server2.vesync.com and then run:

docker pull tonyapuzzo/vesync-wsproxy
docker run -d --name=vprox --rm -p 16522:16522 -p 17273:17273 tonyapuzzo/vesync-wsproxy
docker logs vprox -f
@TonyApuzzo
Copy link
Author

Hmm, pretty apparent I wrote that issue in a bit of a manic condition. Here is a slightly more clear interpretation of what I'm seeing:

  1. I'm not sure if I have built the app correctly. I had to force the installation of the latest version of ts-node to be able to run the app at all.
  2. I'm not sure what to do with the config.json or how to get the GUIDs. I'm also not sure if it's even needed or not. For now I just copied the sample to config.json assuming that's not the breaking problem.
  3. I set up my network in what I think is the correct manner. I created a CNAME on my local DNS to the proxy server and then arranged for the nodejs app to have a hard-coded IP address for the REMOTE_URL
  4. When I boot up the wifi outlet in this environment, it tries to phone home to the proxy as it should but this is where things seem to fall apart. I get a strange error (above) that it can't parse JSON. It turns out that the parser is getting a loginMessage that is typed as a Buffer instead of a string. I tried a few different decodings of that payload without figuring out what it actually is. I'm not a packet sleuth so I'm not sure but my first guess was that everything actually is OK on my end but that the Vesync people maybe are now encrypting their websocket traffic. I don't know how to check for that though, maybe there is a magic header or something that could be used to understand at least if it is a TLS payload or not.
  5. My other thought is that maybe it is just a build problem so the WS code is incorrectly parsing the payload and there is either a set of versions that I need to use or some code tweaks to get the payload correctly interpreted.

Finally, I have built a Dockerfile and some additional config that makes deploying this whole thing a bit easier. All you have to do is pull my docker image and run it in an environment that has the following two configurations:

  1. The DNS in the network used by the wifi switch must return the IP of the Docker service
  2. The Docker image must be able to do its own DNS query to 8.8.8.8 in order to get the hard-coded IP that it will use as the proxy. This is looked up each time the container is launched.

Any advice on what my real problem is would be greatly appreciated. I can happily upload logs or screenshots or whatever if anyone wants to do some additional investigation with me.

Thank you!

@TonyApuzzo
Copy link
Author

TonyApuzzo commented Dec 14, 2017

Noob question... I think the "dist" folder is not needed? I deleted it and everything seems to (not) work exactly the same. I've never used TypeScript / ts-node / nodemon before.

@superfell
Copy link

@TonyApuzzo did you get anywhere with this? Seeing the same issue, every payload size is a multiple of 16, so I'm guessing the payloads are encrypted now.

@TonyApuzzo
Copy link
Author

Sorry I missed this ... no, I never got it working and assume it is encryption getting in the way now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants