Wrong received frame content when scheduling downlink messages from TTN

Hi!
I want to implement some custom downlink commands to an end-node device. When I use TTN Schedule downlink feature and send down data, I receive the correct port and frame length, however the content of the frame is completely wrong. I guess it has to do with encryption.

Screenshot 2021-08-27 at 16.00.55

Do I need to encrypt the frame payload before I paste into TTN downlink feature? How can I do that easily?

I assume it is AES-CTR using AppSKey or NwkSKey, but what is the IV vector?

Thanks in advance!

It wouldn’t be an encryption issue, unless you’re accidentally taking output before the nodes lorawan stack has performed decryption to remove the encryption TN applies.

Perhaps you could show the sent payload vs the received one. Preferable each as bytewise hexdumps.

Any chance of a mixup re base64 encoding, or how you’re outputting the binary packet buffer from the node for debug display?

I send the following message on fport 1 (frame=0x00):
Screenshot 2021-08-27 at 18.23.43

Which seems to be encrypted to “AA==”:
Screenshot 2021-08-27 at 18.24.12

In LMIC code I am printing the frame using in hex format:

            for (i = 0; i < LMIC.dataLen; i++)
            {
                printf("%02X", LMIC.frame[i]);
            }

which outputs:
60

But I now realised that this is just the first byte of MHDR. So I am taking the wrong data variable from the LMIC library. So will have to dig into the library to take the correct thing😊

Or just look at the examples / docs which explains where the actual start of the payload frame is.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.