Vraag

Validatie Tokens van DevEUI_location en DevEUI_downlink_Sent berichten

  • 27 oktober 2017
  • 13 reacties
  • 700 keer bekeken

Hallo,

Wij willen graag tokens valideren van de berichten naar onze applicatie.
De documentatie zegt alleen iets over het valideren van tokens voor DevEUI_uplink.
Het lukt ons niet om de tokens voor de andere berichten te valideren.

13 reacties

Reputatie 6
Badge +6
Goedemiddag @rikvdh,

Welkom bij onze IoT Community! 😁
Goed dat u de vraag hier geplaatst heeft.
Een van onze productmanagers voor LoRa heeft een topic geplaatst over 'Uplink and downlink messages signed with SHA tokens'.

Ik adviseer u aan de hand van dit topic aan de slag te gaan met de validatie 😉

Als u er niet uitkomt hoor ik dat natuurlijk graag!
Beste Rick,

Ik heb dit gelezen. Ik heb ook andere berichten gelezen. Echter voor het gedeelte 'body-elements' wordt er gesproken over gedeeltes die helemaal niet in location of downlink_sent berichten zitten.

From the body of you LoRa message you need some elements which you concatenate without separator: CustomerID, DevEUI, FPort, FCntUp, payload_hex.

Met een DevEUI_location bericht is er bijvoorbeeld geen FPort, FCntUp en payload_hex.
Reputatie 6
Badge +6
Goedemiddag Rik,

Bedankt voor uw snelle antwoord!
Ik ga uw vraag bespreken met onze specialisten om te achterhalen hoe u de tokens in de andere berichten kunt valideren. Ik vermoed hier begin volgende week antwoord op te hebben. Natuurlijk houdt ik u op de hoogte!

Fijn weekend alvast!
Reputatie 6
Badge +6
Goedemorgen Rik,

Het heeft even geduurd, maar ik heb antwoord van de specialisten.
Het klopt inderdaad dat er in het topic dat ik eerder stuurde geen aandacht wordt besteed aan DevEUI_location berichten.
Ik ben daarom met de specialisten uit gaan zoeken welke informatie door de applicatie server gebruikt wordt voor de body-elements.

Hieronder overzicht:
  • Uplink frame: CustomerID, DevEUI, FPort, FCntUp, payload_hex. Voorbeeld: 100000507000000000F1D8693270110027bd00
  • Downlink frame: CustomerID, DevEUI, FPort, PCntDown. Voorbeeld: 100000507000000000F1D8693222
  • Location report: CustomerID, DevEUI. Voorbeeld: 100000507000000000F1D8693

Het klopt dus dat u bij een location bericht geem FPort, FCntUp en payload_hex gebruikt.
Is uw vraag hiermee beantwoord?
Beste Rik,
Bedankt voor uw reactie, helaas heb ik nog een probleem met de location report validatie.. Uplink frame en Downlink frame kan ik juist valideren.

Voor location report maak ik gebruik van de CustomerID + DevEUI + query string (tot aan &token=) + application key.

Kunt u nagaan wat ik hier fout doe?

Joost
Reputatie 6
Badge +6
Goedenavond @jraats,

Welkom bij onze IoT Community! 😁
Ik duik hierin en ga direct op onderzoek uit. Als ik gevonden heb waar dit fout gaat bent u natuurlijk de eerste die het van mij hoort!
Reputatie 6
Badge +6
Goedemiddag @jraats,

Inmiddels heb ik in samenwerking met de specialisten meer duidelijkheid gekregen. Voor location report uplink berichten is inderdaad opgebouwd uit CustomerID,DevEUI. De bestaan uit de DevEUI, FPort, Service profile name, Application Server ID en Time. Een voorbeeld hiervan is:

LrnDevEui=000000000F1D8693&LrnFPort=2&LrnInfos=UPHTTP_LAB_LORA&AS_ID=app1.sample.com&Time=2016-01-11T14:22:22.333+02:00.

Een voorbeeld van is dan:

SHA-256(100000507000000000F1D8693LrnDevEui=000000000F1D8693&LrnFPort=2&LrnInfos=UPHTTP_LAB_LORA&AS_ID=app1.sample.com&Time=2016-01-11T14:22:22.333+02:0046ab678cd45df4a4e4b375Eacd096acc)

Hierbij is 46ab678cd45df4a4e4b375Eacd096acc de 128 bits LRC-AS key. Kunt u nagaan of u deze parameters juist hebt gedefinieerd en gebruikt?
@jraats
Het is mij gelukt om de token te valideren van een DevEUI_location message.
In mijn geval was de DevEUI property in het bericht ge-uppercased (wat denk ik een fout is).
De lrnDevEui in de querystring was wel juist.
Voor mij was het voldoende om deze propery naar lowercase te zetten.
@gpssecurity
Bedankt voor uw reactie! Het is mij nu ook gelukt om het token te valideren. De case mismatch van DevEUI was inderdaad het probleem.
Voor mij was het voldoende om deze propery naar lowercase te zetten.

Inderdaad, dit was voor mij de 'missing link'!

Het is een hele puzzeltocht geworden!
Al eerder ontdekte ik de hex-string die gemaakt wordt van het '+'-teken in de aangeleverde query, en het feit dat de LRC_AS ook naar lowercase geconverteerd moet worden (ondanks als uppercase in het contract)...

Nogmaals het advies aan de KPN om deze informatie tot op de laatste komma juist te communiceren!

Downlink frame: CustomerID, DevEUI, FPort, PCntDown.
Voorbeeld: 100000507000000000F1D8693222


Beste Rick, als ik dit lees, dan betekent dit dat PCntDown ook gecommuniceerd dient te worden naar ThingPark...

Downlink frame: CustomerID, DevEUI, FPort, PCntDown.
Voorbeeld: 100000507000000000F1D8693222


Beste Rick, als ik dit lees, dan betekent dit dat PCntDown ook gecommuniceerd dient te worden naar ThingPark...


Al opgelost Rick, je bedoelde de validatie van de Thingpark response op een downlink-request...
Btw, je bedoelde FCntDn.

Het zou veel helpen als op een centrale plaats de actuele en correctie documentatie wordt bijgehouden. Ik blijf het toch zeggen hoor! 😀
Reputatie 1
Badge
Ik heb nog een vraag, of eigenlijk eerder een observatie m.b.t. de casing van het DevEUI voor validatie met het token:

Bij DevEUI_uplink berichten worden de DevEUI in de body en de LrnDevEui in de querystring beiden in uppercase gestuurd. Dit moet je zo laten aangezien de token blijkbaar ook met een uppercase DevEUI is berekend.

Bij DevEUI_location berichten wordt de DevEUI in de body in uppercase verstuurd, maar de LrnDevEui in de querystring in lowercase. Hier moet je de body DevEUI naar lowercase converteren voor een correcte validatie (zoals eerder in deze thread al opgemerkt).

Erg consistent is dit niet...

- Zijn hier bug-fixes te verwachten?
- Is het verstandig om een bepaalde casing te forceren om aan validerende kant ongevoelig voor KPN wijzigingen te worden?
- Zijn er nog meer velden die onderhevig zijn aan case wijzigingen? Onze AS_ID is toevallig helemaal lowercase.

Reageer