"Waiting for request" never returns results

rhyswj commented 5 years ago

I'm running Raspbarian on my Raspberry Pi Zero W, have installed homebridge and a Tuya plugin. When I try and configure the Tuya plugin to find the ID and Keys of my Tuya (Teckin) smart plugs, I just constantly get "waiting for request".

I've followed the instructions here several times, installing and uninstalling multiple times, but nothing seems to change.

I manage to install the certificate on my iPhone, trust it, and add the proxy. However, when I reload the Tuya app, the console remains on "waiting for requests" and I get a network connection error on my iPHone (although, weirdly, iMessage still seems to work and I can still turn my plugs off from the app).

I'm at the end of my tether - tried to find other threads with my problem but they all seem to be resolved for different reasons/don't apply to me. I've literally followed the instructions to the dot! Help!

digitalec commented 5 years ago

I've encountered the same problem. Full trust is enabled on the certificate as well but still no output.

codetheweb commented 5 years ago

Have you guys force-quit the app to remove it from the background and reopened it?

I've found I sometimes need to do this to trigger the network request we're sniffing for.

digitalec commented 5 years ago

I did. Even rebooted my phone. Ended up using Burp Suite on Windows and that works so I know the phone side was done correctly

codetheweb commented 5 years ago

Hmm. AnyProxy isn't the greatest but has generally been reliable for me.

Are you able to see network requests if you go to http://localhost:8002/ on the computer that's running the proxy?

rhyswj commented 5 years ago

I rebooted my phone, reflashed my pi, installed everything from scratch....tried everything! Currently in an airport so will try that later.

On 17 Jun 2019, at 05:23, Max Isom notifications@github.com wrote:

Hmm. AnyProxy isn't the greatest but has generally been reliable for me.

Are you able to see network requests if you go to http://localhost:8002/ on the computer that's running the proxy?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

codetheweb commented 5 years ago

If all else fails you can use Burp or Charles and extract the key manually.

The field you're looking for is localKey; more detailed instructions can be found here.

NanoSector commented 5 years ago

I couldn't get it working on my iPhone 8 either, but it works fine on an Android device. I even tried logging out and back in with no avail.

rhyswj commented 5 years ago

Managed to do it with Charles! much simpler than doing it in the cmd interface of a Pi. Surprised it isn't suggested as the default way to get the key.

codetheweb commented 5 years ago

👍

It was the suggested method until I implemented the CLI interface; the upside that was supposed to come with using the CLI was an easily-reproducible environment as well as not having to install anything extra. Not sure if those benefits ever actually materialized.

raymondle commented 5 years ago

AnyProxy maybe not working on iOS 12.x. Switch to Android device and it's work but If anyone want to using iOS, you should using Charles for capture request.

Apollon77 commented 5 years ago

We are also trying to find reason for anyproxy not working. It is not iOS 12 because I can fetch e.g. Amazon app requests. It seems that tuya app checks it somehow. But we still research.

tonysprenk commented 5 years ago

I’m also having trouble with AnyProxy. I don’t think it’s iOS (i’m Running iOS 13 beta) because I can see the traffic from and to Tuya on the AnyProxy web page. If there’s anything I can help out with, please let me know.

Apollon77 commented 5 years ago

see also https://github.com/TuyaAPI/cli/issues/19 and/or https://github.com/Apollon77/ioBroker.tuya/issues/56 ... it seems to be that app version 3.9 works, but 3.10 not ... for Android it id easy possible to downgrade.

Someone here that is able to decompile APKs to check differences between both versions?

I assume they switched to client certificates OR verify the cert chain somehow

kueblc commented 5 years ago

@Apollon77 I can take a look. 3.9.5 and 3.10.0?

Apollon77 commented 5 years ago

Latest info was that android seems also to work with 3.10 ... so this would mean only iOS could be affected :-(

But maybe it would be good to verify that the proxy approach with anyproxy is still working on android.

It is also interesting that Charles proxy with their cert is still working also on iOS ... but also using their rootca (at least in my tests) it was not working on anyproxy.

Any help or ideas is much appreciated ...

codetheweb commented 5 years ago

Just checked and it's not working for me either (iOS). It was working about 1.5 weeks ago, so they must have updated it since then.

In AnyProxy I'm just seeing a bunch of CONNECT requests with no actual information exchanged; is that consistent with what you guys are seeing?

Apollon77 commented 5 years ago

I tested with an older iOS but current App, also not working. So it is not because of iOS version. :-(

@codetheweb: Yes it seems that the app is not sending data after connect. But Anyproxy itself is still working ... For Alexa App it looks like:

[AnyProxy Log][2019-06-25 00:22:40]: received https CONNECT request latinum-eu.amazon.com
[AnyProxy Log][2019-06-25 00:22:40]: will forward to local https server
[AnyProxy Log][2019-06-25 00:22:40]: [internal https]proxy server for latinum-eu.amazon.com established
[AnyProxy Log][2019-06-25 00:22:40]: received request to: GET latinum-eu.amazon.com/v20160207/ping

For tuya it only looks like

[AnyProxy Log][2019-06-25 00:23:08]: received https CONNECT request a1.tuyaeu.com
[AnyProxy Log][2019-06-25 00:23:08]: will forward to local https server
[AnyProxy Log][2019-06-25 00:23:08]: [internal https]proxy server for a1.tuyaeu.com established

... and nothing afterwards. So it seems that the app is not sending a request after the successfull connection :-(

Apollon77 commented 5 years ago

I will try an Android Emulator later today, maybe this is a way to got for now for the iOS users ... and then use the proxx approach ... (so roughly as https://community.home-assistant.io/t/alternative-tuya-smart-outlet-setup/51830)

But still trying/interested to solve the iOS topic

davidplappert commented 5 years ago

Any updates? I just ran into this today. I don't have an Andriod device. Any clues to get it to work otherwise? Thanks!

Apollon77 commented 5 years ago

Not till now, but for me it worked with the Android Emulator approach.

Basically:

install Genymotion (Android Emulator, Free for personal usage) and pot. Virtualbox
choose a device and Android version from the list and setup the virtual Android device
Install matching ARM parsing package for the choosen Android version from https://pentester.land/tips-n-tricks/2018/10/19/installing-arm-android-apps-on-genymotion-devices.html (download file, drag/drop to the device window)
Download APK from https://apkpure.com/smart-life-smart-living/com.tuya.smartlife (also drag/drop to device to install) Before this pot. enable that you allow to install APK from external sources
Download certificate as usual, maybe open webpage from proxy-admin port and select "Download ROOTCA". Install certificate depending on Andreoid version you need to select "Wifi" or "VPN and apps" (or just install for both ... so two times) :-)
Then long click on the "Wifi" connection and "change config" and set proxy IP and Port
Then open Smart Life App ... Rest should be as usual

Maybe someone finds time to compile that with images as a guide to add to docs...

I have no idea how I could debug that further for now on iOS :-( maybe I need some days distance to get new ideas ...

raymondle commented 5 years ago

Any updates? I just ran into this today. I don't have an Andriod device. Any clues to get it to work otherwise? Thanks!

Hi, you can use any Android emulator support Wifi Proxy such as Genymotion, MEmu, etc. Or you can using charles proxy on Windows or Mac for debug in iOS. I was test on charles proxy and it's working.

Apollon77 commented 5 years ago

@raymondle Charles is not helping with the "cli link process" because this one is working via Anyproxy ...

raymondle commented 5 years ago

@raymondle Charles is not helping with the "cli link process" because this one is working via Anyproxy ...

Sure! But you can capture request and found localKey because Charles can be decrypt ssl request content than AnyProxy at this time when work with iOS. And same like you i'm prefer using Android Emulator than using Charles because it not free :(

codetheweb commented 5 years ago

@davidplappert you can use Charles for now. Old instructions for using Charles are here.

@raymondle is right in saying that Charles isn't free; however the trial version works fine for capturing Tuya requests.

masipulami commented 5 years ago

I am also facing the same issue while trying to get my device ids via tuyacli.

Just realized that the instructions for using Charles are only for MacOS and Android.

Does it also work with Windows?

codetheweb commented 5 years ago

Charles is available in a Windows version; so while I haven't tried it myself I assume it would work @masipulami.

masipulami commented 5 years ago

Thanks for your answer @codetheweb. I was finally able to get it working.

I extracted the following information for one of my devices:

uuid productID localKey

I am using the NodeRed contribution and am trying to connect to the device.

I habe entered the localKey as key but none of the two ids above seems to work for deviceid .

I used the local ip of the device as IP. But no connection is possible.

Any idea? Do I have to combine the two ids above so that I can use them as productid?

codetheweb commented 5 years ago

The device ID is denoted as the devId in Tuya requests.

masipulami commented 5 years ago

Ah, I see. And for key I use localKey?

IP is the local IP of the device correct?

codetheweb commented 5 years ago

And for key I use localKey?

IP is the local IP of the device correct?

Correct.

masipulami commented 5 years ago

Unfortunately my NodeRed node is still not able to connect.

Using Charles I was able to extract devid and localkey, put the values as device id and device key in nodered together with the local ip of the plug but then get a "disconnected" after deployment in NodeRed.

lherlitz commented 5 years ago

Charles instructions followed and I still can't find ID and KEY. All I get is gibberish.

codetheweb commented 5 years ago

@masipulami you may have devices with v3.3 firmware. Please try getting/setting state with the CLI tool and see if that works. If it doesn't, please open a new issue.

@lherlitz I'm guessing the root SSL certificate wasn't installed correctly.

masipulami commented 5 years ago

Using the cli with the local IP of the device poses the following problem:

pi@raspberrypi:~ $ sudo tuya-cli get --ip 192.168.178.42 Usage: get [options]

get a property on a device

Options: -s, --save save key so you can omit it for subsequent commands --ip ip address of device --id id of device --key [key] key of device --dps [dps] property index to get (default: 1) -a, --all get all properties of a device -h, --help output usage information

masipulami commented 5 years ago

OK, seems I had to pass more arguments.

Now I get "error from socket":

pi@raspberrypi:~ $ tuya-cli get --ip 192.168.178.42 --id 38272685dc4f22e92563 --key 68379fd576eb1963 -a events.js:183 throw er; // Unhandled 'error' event ^

Error: Error from socket at Socket.client.on.err (/usr/lib/node_modules/@tuyapi/cli/node_modules/tuyapi/index.js:365:30) at emitOne (events.js:116:13) at Socket.emit (events.js:211:7) at onwriteError (_stream_writable.js:417:12) at onwrite (_stream_writable.js:439:5) at _destroy (internal/streams/destroy.js:39:7) at Socket._destroy (net.js:568:3) at Socket.destroy (internal/streams/destroy.js:32:8) at WriteWrap.afterWrite [as oncomplete] (net.js:870:10)

codetheweb commented 5 years ago

@masipulami please open a new issue with the output of DEBUG=* tuya-cli get --ip 192.168.178.42 --id 38272685dc4f22e92563 --key 68379fd576eb1963 -a

masipulami commented 5 years ago

@masipulami please open a new issue with the output of DEBUG=* tuya-cli get --ip 192.168.178.42 --id 38272685dc4f22e92563 --key 68379fd576eb1963 -a

Ok, it's done: https://github.com/codetheweb/tuyapi/issues/226

niksauer commented 5 years ago

@lherlitz Have you managed to decrypt the gibberish? I'm getting the same output even though I followed the instructions here. Or what do you mean by I'm guessing the root SSL certificate wasn't installed correctly. @codetheweb, shouldn't it be added to macOS automatically by Charles? I've added to iOS as per instructions.

codetheweb commented 5 years ago

@niksauer you don't need to add the certificate to macOS, only the iOS device.

Are you able to view decrypted requests if you open a random HTTPS site in iOS Safari?

kieranju commented 5 years ago

@lherlitz @niksauer I was experiencing the same thing (iPhone 8, iOS 12.3, Charles on Windows 10 spitting out gibberish). Turns out I had to set the location to be proxied, as there was nothing set by default.

In Charles:

Proxy > SSL Proxying Settings...
SSL Proxying tab.
Ensure "Enable SSL Proxying" is checked.
"Add" button to add a new Location.
Set this new location to "*.*" without quotes for all traffic, or set it as needed.

tsightler commented 5 years ago

It definitely seems I'm unable to use tuya-cli to get the list with the 3.10.1 version of the Smart Life app for Android. I was able to grab what I needed easily enough using the Packet Capture app, so that's good. The instructions show how to do this when adding/re-adding a device, but you don't really need to do this, you can just refresh the app and you get a nice decode with all the JSON data.

If I get a chance in the next few weeks I'll try to see what's going wrong with the tuya-cli, I suspect it has to be something simple.

niksauer commented 5 years ago

@kieranju @codetheweb Thanks a lot, this was the issue. Isn't it scary to be able to view all traffic in cleartext? Sadly I'm now stick at this issue https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/33. Is there any list of known compatible devices before I go and purchase a new outlet? @tsightler Guess re-adding a device is meant to make it easier to distinguish the new one from existing ones. However I've noticed that the query parameter of the first request including the necessary information has changed to tuya.m.device.get.

codetheweb commented 5 years ago

@tsightler you may want to start your search in AnyProxy, as everything I've seen so far points to that being the culprit.

@niksauer I'm not aware of a list of compatible devices at the moment, might be good to start one.

And you're correct; re-adding the device is not necessary but I never got around to updating the instructions.

Hussamfhaily commented 5 years ago

And for key I use localKey? IP is the local IP of the device correct?

Correct.

there is more than one localkey. which one should one use? Thanks

kueblc commented 5 years ago

@Hussamfhaily there is only one localKey per device per registration.

verisgit commented 5 years ago

If you can't get it working or the waiting for request just times out then try this guide http://www.htgsd.com/information-technology/apple/homekit/how-to-capture-tuya-lan-homebridge-device-devid-and-key-on-windows-10/

codetheweb commented 5 years ago

I just shipped v1.8.1 of the @tuyapi/cli package with a tentative fix, please try it out and let me know if it works.

Do note that since I switched from using AnyProxy to using http-mitm-proxy, you'll have to re-scan the generated QR code and go through the certificate trust process again.

Leaving this issue open until I get at least one confirmation that it works for others.

Apollon77 commented 5 years ago

Forks for me basically

Feiremoore commented 5 years ago

It worked for me a few weeks ago with Android, but no longer.

codetheweb commented 5 years ago

@Feiremoore https://github.com/codetheweb/tuyapi/issues/250#issuecomment-534273167

codetheweb / tuyapi

"Waiting for request" never returns results #215