Received corrupted data with loraserver and Rn2483

1

Versions:
lora-app-server version 2.4.1
loraserver 2.4.1
rn2483 firmware version 1.0.4

I have the following problem:

The end device’s controller sends the following chars via uart to rn2483: mac tx cnf 1 06000800\r\n
. I listened to the tx line and the controller is actually sending these bytes to the rn2483 (thus it is not just a source code assumption). Then the rn2483 transmit successfully.

The Loraserver on the other hand receives 1ZpksA== but it should be BgAIAA==
The bytes are different for every transmission.

This does not happen with every end device, actually it’s quite rare but once I identify an end device it happens very time when this end device transmits data.

I haven’t created a new lorawan session (rejoin) yet because I want to analyze the behaviour in more detail first.

It sounds like the problem nobody wants to have and I appreciate any clues that can help.

2

Is this an ABP or OTAA device? Please note that LoRa Server doesn’t decrypt the data but LoRa App Server does. Could you confirm that the 1ZpksA== payload is the decrypted payload from LoRa App Server?

To further analyze the issue, what you can do is look at the raw LoRaWAN frmPayload field. Then you could try to decrypt the payload yourself using the following function: https://godoc.org/github.com/brocaar/lorawan#EncryptFRMPayload.

3

OTAA.
lora-app-server, I am speaking of loraserver as a whole (lora-gatewaybridge, loraserver, lora-app-server).

It is the decrypted data.

I have a look at the raw payload and decrypt it.

4

Another observation:
A downlink message gets corrupted as well.
When I enqueue the bytes 06000101 on port 1 I get
mac_rx 1 E88CEA3C on the end device and the payload arriving at the end device is also different every time I send the same downlink.

5

I decrypted via lora-packet (https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh)
Phy Payload: gBTRwwGDpAAG9gYBrfgFI46nWaU
NwkSKey: cf4937ba62590dc70c403a50ce8ee6ea
AppSKey: a0b057de020ba44ee201364ad478c750

Given that the decrypted payload doesn’t match, I fear the problem is inside the rn2483 firmware.

It is also very rare (0.03% so far).

Assuming base64-encoded packet
gBTRwwGDpAAG9gYBrfgFI46nWaU

Message Type = Data
  PHYPayload = 8014D1C30183A40006F60601ADF805238EA759A5

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
    MHDR = 80
  MACPayload = 14D1C30183A40006F60601ADF80523
     MIC = 8EA759A5 (from packet)
         = 8EA759A5 (expected, assuming 32 bits frame counter with MSB 0000)

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 14D1C30183A40006F606
       FPort = 01
  FRMPayload = ADF80523 (from packet, encrypted)
             = 2FE261A1 (decrypted)

  ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
 DevAddr = 01C3D114 (Big Endian)
   FCtrl = 83
    FCnt = 00A4 (Big Endian)
   FOpts = 06F606

Message Type = Confirmed Data Up
   Direction = up
        FCnt = 164 (from packet, 16 bits) 
             = 164 (32 bits, assuming MSB 0x0000)
   FCtrl.ACK = false
   FCtrl.ADR = true