search

anthonykirby / lora-packet

LoRa radio packet decoder
MIT License
261 stars 83 forks source link

Decoding 1.1 LoRaWAN payload #127

Open tanguy-e opened 8 months ago

tanguy-e commented 8 months ago

Hello, i'm trying to use lora-packet-decode to decode payload : lora-packet-decode --nwkkey 95AC484C0B6CA199F80311CADAA774C1 --appkey F5D893278F7E3F23C3DAB5A19AE0CD6C --base64 QPjyCyaAhAEKxgot72bu6AZmyLrY and i obtain : 

      ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
              MHDR = 40
        MACPayload = F8F20B268084010AC60A2DEF66EEE806
               MIC = 66C8BAD8 (BAD != 83269847)

      ( MACPayload = FHDR | FPort | FRMPayload )
              FHDR = F8F20B26808401
             FPort = 0A
        FRMPayload = C60A2DEF66EEE806
         Plaintext = 7665F6EBEE99543D ('ve....T=')

            ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
           DevAddr = 260BF2F8 (Big Endian)
             FCtrl = 80
              FCnt = 0184 (Big Endian)
             FOpts = 

      Message Type = Unconfirmed Data Up
         Direction = up
              FCnt = 388
         FCtrl.ACK = false
         FCtrl.ADR = true
   FCtrl.ADRACKReq = false

Where it seems there is a problem concerning MIC. Is this problem come from the use of LoRaWAN version 1.1 or other ? Thanks Eric

anthonykirby commented 8 months ago

Hi Eric, is it possible that you didn't set the top 16 bits of Fnct? see similar issues

thanks Anthony

On Tue, 26 Mar 2024 at 13:22, tanguy-e @.***> wrote:

Hello, i'm trying to use lora-packet-decode to decode payload : lora-packet-decode --nwkkey 95AC484C0B6CA199F80311CADAA774C1 --appkey F5D893278F7E3F23C3DAB5A19AE0CD6C --base64 QPjyCyaAhAEKxgot72bu6AZmyLrY and i obtain :

  ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
          MHDR = 40
    MACPayload = F8F20B268084010AC60A2DEF66EEE806
           MIC = 66C8BAD8 (BAD != 83269847)

  ( MACPayload = FHDR | FPort | FRMPayload )
          FHDR = F8F20B26808401
         FPort = 0A
    FRMPayload = C60A2DEF66EEE806
     Plaintext = 7665F6EBEE99543D ('ve....T=')

        ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
       DevAddr = 260BF2F8 (Big Endian)
         FCtrl = 80
          FCnt = 0184 (Big Endian)
         FOpts =

  Message Type = Unconfirmed Data Up
     Direction = up
          FCnt = 388
     FCtrl.ACK = false
     FCtrl.ADR = true

FCtrl.ADRACKReq = false

Where it seems there is a problem concerning MIC. Is this problem come from the use of LoRaWAN version 1.1 or other ? Thanks Eric

— Reply to this email directly, view it on GitHub https://github.com/anthonykirby/lora-packet/issues/127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKVFHMABWYEMCF2DAW3FODY2FR6PAVCNFSM6AAAAABFI5RC72VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDQMRTGQ3TOMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

tanguy-e commented 8 months ago

Hi Anthony, the frame is well decoded in TTN because i took it in end device live data. And the frane counter value is good. The result is the same using https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=QPjyCyaAhAEKxgot72bu6AZmyLrY&nwkskey=95AC484C0B6CA199F80311CADAA774C1&appskey=F5D893278F7E3F23C3DAB5A19AE0CD6C The library i use to send data is 1.1 compliant https://github.com/jgromes/RadioLib/tree/master/examples/LoRaWAN and it seems that there is a big difference between 1.0.x and 1.1 for coding/decoding MIC. Thanks Eric