Message parser fails to parse UDP message when using find()

Describe the bug The find() function fails when the decipher functions does not trigger “catch”, i.e. decipher thinks it was able to decrypt the data when in fact it was not.

To Reproduce I have a protocol 3.3 device and when I attempt to use find(), it fails but only when I use the “proper” device key. If I use the wrong device key (even just change one number) then find() works. Digging through this, the issue seems to be in the decrypt data function. The code attempts to decrypt the data with the device.key, and, for some reason, with this device and this specific key, it thinks decryption was successful and returns back to to the find() function the improperly decrypted message instead of falling through to the catch block and attempting to decrypt with the UDP_KEY.

Expected behavior The decrypt with the device.key should fail, and the catch block should execute the decrypt with the hardcoded UDP_KEY.

Debug Output The problem happens with tuya-mqtt, but I’ve reproduced with tuya-cli, exactly the same. Here’s an example of the UDP debug when the issue occurs:

  TuyAPI UDP data: +9ms
  TuyAPI {
  TuyAPI   payload: '4h}��\u0005�:-���^�/]5��ԝqI��4�\u0017���.\u000e\u0001�A߯X��)�DU��UP��lf�9\\�p�\u0003�D�-��\u0017��y�\u0010г�Ϫf;zc\u0019\u001c��\u0001iKTv\u0003�gN\u0007��P�c�"$�\t���\u0013�\n' +
  TuyAPI     `�A4?#�g/�q\u0019\u0013�\u0004\u0000;'wK"��׹8.�J� ������}��\u0002ؤ`,
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0
  TuyAPI } +0ms

Additional context As a hackish workaround, I just change decrypt function to attempt UDP_KEY prior to device.key, and things work, however, I don’t like this as it means that for “non-find” operations every packet fails decryption first.

I can probably work around this in my app by simply temporarily using the hard coded key for the find() function and, only after the device is found, creating the “real” device, but it seems like a better option is preferred, I’m just not sure what that would be.

I can think of several possible ways to fix this, but none seem particularly clean. A simple flag passed to message parser is probably one of the easiest, that way decrypt can explicitly know to use UDP_KEY instead of rely on decryption failing. I’m hoping someone a little closer to the code has a better idea.

[tsightler]

Yep, works great, and much cleaner than my client side workaround that I implemented last night.

[tsightler]

Awesome, thanks!