Unable to link devices - timeout

[milo526]

Hello,

I'm trying to link Tuya devices using this CLI tool but I can't seem to get any other response then a timeout.

I'm running the homebridge raspbian image on a Raspberry pi 3B. I have added an SSH-key, enabled WiFi, installed this CLI and removed the ethernet cable.

I then reset my Tuya power by pressing the power button 6 seconds (it will start to blink) And then I run the following command on my Pi:

tuya-cli link --ssid 'My Wifi SSID' --password 'MyWifiPassword!' --api-key 'a-tuya-app-key' --api-secret 'a-tuya-app-secret' --schema 'a-tuya-schema' -t 'Europe/Amsterdam' -r 'eu'

My SSID contains spaces, my wifi password contains an exclamation mark.

When capturing network traffic on my MacBook during the command, I can see UDP broadcast packets with destination port 30011; the timing and payload seems to strongly suspect that these originate from this CLI.

In the Tuya IoT Platform, all API groups are "open"

Do you have any idea what might prevent my from linking my devices and or what I can do to help debug this?

I am investigating this for use in a homebridge-plugin therefor it is not useful for me to simply link my app account and extract the keys that way. (linking app accounts would not be a viable solution for other users of the plugin)

[milo526]

And I should have tried this before - removing the space from the SSID fixed the problem.

Do you know if there is an option to keep the spaces in the SSID?

[codetheweb]

I've heard similar reports before.

Nothing stands out to me in the encoding logic as influencing this. My first guess was that UTF8 and ASCII had different encodings for the space character, but that's not the case.

[milo526]

So when removing the spaces from the SSID, linking works properly.

When also changing all buffers in this code (also in the link and wizard libraries) to use ascii encoding, the linking fails. Changing them to utf8 works properly. Which makes me strongly suspect that utf8 is indeed the correct encoding.

[codetheweb]

Cool, glad you figured it out. Happy to accept PR(s) with the fixes. :)

[milo526]

I don't believe there are any improvements to be made at the moment.

At most a warning when an SSID contains spaces but I don't know if that is desired.

[codetheweb]

🤔 it sounds to me like there's a clear bug with a known solution...

[milo526]

I wanted to try and see if I could figure out what the problem was here thus I started capturing some data using Wireshark.

I captured the link process once when invoked through the tuya app; and once when invoked through the link/wizard library.

Both the preambles were identical (a bunch of UDP packets with bodies of length 1,3,6,10 repeated).

Then the actual useful data starts with the headers calculated here since the same SSID and Password are used, it is expect that these are equal. They are indeed equal.

From there on we have sets of 6 packets that we take into consideration. First the CRC for the other 5 packets, then some sort of index/counter, then 4 data packets. All the data that is encoded is constructed here

The first 5 sets of 6 packets have identical contents, everything matches up.

The 6th through 9th packet have mis-matches. This is to be expected since they (in my specific case due to the length of my pwd) contain some request specific token (see also)

The further series of packets (so 10th and later) contain no more differences between the two captures. The Wifi SSID starts in the 9th packet, the part that contains the SSID is equal however the CRC mismatches since there is still 2 characters of the token in this series.

The space in the Wifi SSID only occurs in the 10th series. Which has identical contents in the crc, counter and data.

Therefor I'd like to conclude that I have no freaking idea what goes on here. Why Tuya manages to get spaces in SSID's to work but your library doesn't since it works seemingly identical.

@codetheweb, if you are interested in the captures, please email me (my email address can be found on my profile). I'm not sharing them here since they contain my wifi SSID and password in plaintext 😛

[milo526]

When extracting the token and secret from the capture that the Tuya App sent and inputting that into smartLinkEncode , the output is fully identical to the captured data.

[codetheweb]

When extracting the token and secret from the capture that the Tuya App sent and inputting that into smartLinkEncode , the output is fully identical to the captured data.

Well, now I'm even more confused. 😛

I assume the generated packets with utf8 encoding instead are also identical?

[milo526]

The default is utf8, these packet are identical

Since utf8 allowed me to connect (at least to a SSID without spaces) I did not try ascii.

[codetheweb]

Oh ok, my bad. I think I originally misunderstood

So when removing the spaces from the SSID, linking works properly.

When also changing all buffers in this code (also in the link and wizard libraries) to use ascii encoding, the linking fails. Changing them to utf8 works properly. Which makes me strongly suspect that utf8 is indeed the correct encoding.

as "changing buffers to utf8 allows SSIDs with spaces to be used". Sorry.

But yeah I'm not sure what the difference could be if the packet captures are identical.