Communication problem : same frame for different sessions?

ChirpStack Network Server
1

Hello guys,

I managed to setup a lora server with my end device. I was able to communicate (the end-device turns on a led when it receives a frame with a particular payload, say 0x10).

I moved my end device to another floor, and the communication started failing (the end-device light never went on) . I thought the device was out of range but when I checked the logs, I saw that the end-device and loraserver were able to communicate, but the received payload on the end-device side wasn’t the expected one. Instead of 0x10, I got a random value each time different.

I started to have a closer look at the received frames. Each time the end-devices reboots, a new JoinRequest is made, and I can see the JoinAccept that is received. For example for 2 consecutives reboots, I get:

decoding from Base64:  AEFYSU9NLUxHAAIVdAQAAAAGTpiXwf8=
Decoded packet
--------------
Message Type = Join Request
      AppEUI = 474C2D4D4F495841
      DevEUI = 0000000474150200
    DevNonce = 4E06
         MIC = 9897C1FF
----------------------------------------------------------------------------------------------
decoding from Base64:  IEa40vVaMmp08hseQe9ZqRE=
Decoded packet
--------------
Message Type = Join Accept
    AppNonce = D2B846
       NetID = 325AF5
     DevAddr = 1BF2746A
         MIC = EF59A911
---------------------------------------------------------------------------------------------
decoding from Base64:  AEFYSU9NLUxHAAIVdAQAAAB/9bbFjbk=
Decoded packet
--------------
Message Type = Join Request
      AppEUI = 474C2D4D4F495841
      DevEUI = 0000000474150200
    DevNonce = F57F
         MIC = B6C58DB9
--------------------------------------------------------------------------------------------
decoding from Base64:  IGuhOhJ66DSn0l7evxZCFdU=
Decoded packet
--------------
Message Type = Join Accept
    AppNonce = 3AA16B
       NetID = E87A12
     DevAddr = 5ED2A734
         MIC = 164215D5

So this seems correct to me, a new DevAddr is generated at each reboot. But when I looked at the frame that should turn on the light, I noticed it was always the same physicial payload.

decoding from Base64:  oF8OdQaAAQAKaDnuMcva
Decoded packet
--------------
Message Type = Data
  PHYPayload = A05F0E75068001000A6839EE31CBDA

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = A0
  MACPayload = 5F0E75068001000A6839
         MIC = EE31CBDA

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 5F0E7506800100
       FPort = 0A
  FRMPayload = 6839

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 06750E5F (Big Endian)
       FCtrl = 80
        FCnt = 0001 (Big Endian)
       FOpts =

Message Type = Confirmed Data Down
   Direction = down
        FCnt = 1
   FCtrl.ACK = false
   FCtrl.ADR = true

Isn’t the physicial payload supposed to change when a new DevAddr is issued ? And the DevAddr contained in the frame (06750E5F) isn’t the same as the one received in the JoinAccept. So actually I get all the time the same frame, but my end-device uses the DevAddr received in the JoinAccept to decrypt the payload, so the decrypted value always differ, so my end-device doesn’t turn light on.

Would it be possible that the LoRa Server keeps an old DevAddr in cache or something ?

2

Are there any errors in your LoRa App Server or LoRa Server logs?

3

I tried to reproduce the problem by all means but I wasn’t able to do so… I rebooted the day after the problem and it started working… Very strange

I will post another message here if I ever encounter the same error.

Thanks for your reply