Wrong received frame content when scheduling downlink messages from TTN

[tibhel]

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.

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!

[cslorabox]

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?

[tibhel]

I send the following message on fport 1 (frame=0x00):

Which seems to be encrypted to “AA==”:

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😊

[descartes (Nick McCloud)]

@tibhel

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.