Vraag

FcntUp 16 bit wrap icm decryptie op eigen application server: hoe kom ik aan de volledige 32 bit waarde?

  • 27 februari 2021
  • 3 reacties
  • 30 keer bekeken

De fcntup teller in onze lorawan stack (gebaseerd op semtech loramac-node) is 32 bits. De fcntup velden in de lora communicatie zijn 16 bits, terwijl de encryptie en bepaling van de mic op basis van de volle 32 bits waarde gebeurt. Dit betekent dat het netwerk (dwz de gateway en de application server) de hoogste 16 bits niet uit de berichtdata zelf kan halen, en (soms) zal moeten uitproberen; wanneer de teller de 0xffff gepasseerd is, kan een daarop volgende lage fcntup waarde wijzen op een 16 bit wrap, of op een device reset.

De LRC kan waarden uitproberen om te zien bij welke waarde voor de hoogste 16 bits van de fcntup de mic klopt: een harde check. De application server heeft die mogelijkheid niet, wanneer de payload geen redundante informatie bevat die daarvoor gebruikt kan worden.

Aangezien het netwerk de data aflevert aan onze application server, na validatie van de mic, heeft de LRC per definitie weet van de volledige fcntup waarde. Is er een mogelijkheid voor de application server om deze voor mic validatie gebruikte 32 bit waarde te weten te komen?


3 reacties

Reputatie 6
Badge +6

Goedemiddag @HazelGrace ,

Welkom op het Zakelijk KPN Forum! 
Ik heb uw topic in eerste instantie over het hoofd gezien, waardoor u nu pas een reactie krijgt.. Daarbij komt moet ik eerlijk zeggen dat deze vraag verder reikt dan mijn eigen LoRa kennis. Ik heb daarom uw vraag voorgelegd aan een van de specialisten. Zodra ik een terugkoppeling ontvang dan kom ik uiteraard direct bij u terug. Ik verwacht uiterlijk morgen een terugkoppeling te ontvangen. 

De fcntup teller in onze lorawan stack (gebaseerd op semtech loramac-node) is 32 bits. De fcntup velden in de lora communicatie zijn 16 bits, terwijl de encryptie en bepaling van de mic op basis van de volle 32 bits waarde gebeurt. Dit betekent dat het netwerk (dwz de gateway en de application server) de hoogste 16 bits niet uit de berichtdata zelf kan halen, en (soms) zal moeten uitproberen; wanneer de teller de 0xffff gepasseerd is, kan een daarop volgende lage fcntup waarde wijzen op een 16 bit wrap, of op een device reset.  VidMate

De LRC kan waarden uitproberen om te zien bij welke waarde voor de hoogste 16 bits van de fcntup de mic klopt: een harde check. De application server heeft die mogelijkheid niet, wanneer de payload geen redundante informatie bevat die daarvoor gebruikt kan worden.

Aangezien het netwerk de data aflevert aan onze application server, na validatie van de mic, heeft de LRC per definitie weet van de volledige fcntup waarde. Is er een mogelijkheid voor de application server om deze voor mic validatie gebruikte 32 bit waarde te weten te komen?

 

issue got solved!!

 
Reputatie 6
Badge +6

Goedemiddag Grace, 

Goed om te lezen dat het probleem opgelost is! 
Ik ben stiekem wel benieuwd hoe u tot de oplossing gekomen bent. Kunt u dat nog even toelichten? 

Daar hebben andere forumgebruikers ook veel aan wanneer zij ook tegen dit issue aanlopen. 

Reageer