Retrieve payload from downlink frame?

[Ksemanov]

What is an efficient recipe for extracting a payload from a downlink frame at an edge device?

Below are three separate frames. Spaces have been added for visual effect.

(1) 600b0b0b 009f c825 03000100700330ffff01050868e28c  01187f7ffa ad1af8

(2) 600b0b0b 008f c925 03000100700330ffff01050868e28c  01ad9eb655 316b42 052d7e

(3) 600b0b0b 008f ca25 03000100700330ffff01050868e28c  d5248606

600b0b0b is my device address with a network derived code inserted in the first byte. c825,c925,ca25 are the frame counters incrementing on each frame. (little endian)

(1) contains the payload FADE93

(2) contains the payload FADE93FADE93

(3) contains an empty payload.

So how do I get them out of the frames?

[Jason_Reiss]

Start here
https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/

[Ksemanov]

Moving a little towards documentation. If something is wrong here, I will edit the posts to correct inaccuracies.

A a array of 16 bytes (128 bits) is encrypted using block as the key. The result of that is XOR’d against the payload, in such a way that bytes are pushed to the lefthand side. (see Short Payload)

If the FRMpayload exceeds 16 bytes, it is segmented to 16byte segments. The a array increments a block no. on byte 15 and is re-encrypted. The result is XOR’d against the next 16 byte segment. This is repeated on subsequent segments. block is constant over all payload segments and is often calculated ahead of time and set aside. (see Long Payload)

Justification that device address is actually decorating bytes 6 thru 9 in little endian.

• lines 340 to 343 https://github.com/lemariva/uPyLoRaWAN/blob/LoRaWAN/sx127x.py

• lines 148 to 151 https://github.com/Lora-net/LoRaMac-node/blob/master/src/mac/LoRaMacCrypto.c

• lines 112,113,878 https://github.com/brocaar/lorawan/blob/master/phypayload.go

Returning to the examples from before, we have,

(1) 600b0b0b 009f c825 03000100700330ffff01050868e28c  01187f7f  faad1af8

(2) 600b0b0b 008f c925 03000100700330ffff01050868e28c  01ad9eb655316b 42052d7e

(3) 600b0b0b 008f ca25 03000100700330ffff01050868e28c  d5248606

The FRMpayloads are (1) 01187f7f , (2) 01ad9eb655316b (3) (empty) . The trailing four bytes there are Message Integrity Codes, which are calculated in a completely different way using Network Session Key and other information.

[Ksemanov]

Editing is disabled after a few hours. This is to address inaccuracies above.

The actual encrypted FRM payloads are as follows.

(1) 187f7f

(2) ad9eb655316b

(3) (empty).

I had accidentally included FPort byte =01. Which is transmitted in plaintext.

Notice also that when FRM payload is empty the FPort does not exist.

l