Ik heb ABP al een tijd werkend, maar aangezien ABP niet lang meer ondersteunt gaat worden wil ik eigenlijk OTAA gaan gebruiken.
Nu zou de overstap naar OTAA vrij simpel moeten zijn, (de juiste keys invullen en het OTAA bitje op true zetten). Alleen is het me nog nooit gelukt om een apparaat te activeren.
Nu heb ik laatst een theThingsnetwork account aangemaakt. Daar krijg ik iets meer debug informatie, ik kan daar zien dat er een joinRequest binnen komt. Het antwoord daarop komt echter niet aan op mijn lora apparaat. Maar de reden dat dit niet aan komt is waarschijnlijk omdat de downlink berichten (via abp) zelden aankomen, met hun netwerk. Met jullie netwerk heb ik dat probleem niet. Maar bij jullie kan ik nergens zien of er iets van een joinRequest uberhaubt binnen komt.
Is er een manier om meer debug informatie te krijgen in de devportal?
Mvg,
Ruben
Reputatie 7
+6
Goedemiddag @Ruben
Welkom terug!
Goed om te lezen dat u aan de slag gaat met OTAA. U heeft ongetwijfeld het topic Over the air activation of devices gevonden.
Nu ben ik de Developer Portal in gedoken, maar ik heb tot zover nog geen account van u terug gevonden. Ik wil namelijk checken of er nu devices naar komen en wat voor status deze devices hebben. Wanneer u een Join Request aanmaakt wordt deze voor ons zichtbaar in de Portal. Het device komt dan op de lijst 'To be activated OTAA devices' te staan. Deze lijst wordt dagelijks gecheckt en verwerkt als er nieuwe device bij gekomen zijn.
Wilt u mij een privébericht sturen met het mailadres waarmee u geregistreerd bent, uw gebruikersnaam en de DevEUI's van de devices die u geprobeerd heeft toe te voegen?
Welkom terug!
Goed om te lezen dat u aan de slag gaat met OTAA. U heeft ongetwijfeld het topic Over the air activation of devices gevonden.
Nu ben ik de Developer Portal in gedoken, maar ik heb tot zover nog geen account van u terug gevonden. Ik wil namelijk checken of er nu devices naar komen en wat voor status deze devices hebben. Wanneer u een Join Request aanmaakt wordt deze voor ons zichtbaar in de Portal. Het device komt dan op de lijst 'To be activated OTAA devices' te staan. Deze lijst wordt dagelijks gecheckt en verwerkt als er nieuwe device bij gekomen zijn.
Wilt u mij een privébericht sturen met het mailadres waarmee u geregistreerd bent, uw gebruikersnaam en de DevEUI's van de devices die u geprobeerd heeft toe te voegen?
Reputatie 7
+6
Hi @Ruben ,
Bedankt voor uw gegevens!
Ik ben in de Portal op zoek gegaan naar uw account en ik zie nu 4 geregistreerde devices naar voren komen. Daarvan zijn er als het goed is 2 (DevEUI eindigend op B6A & B6B) via OTAA aangemeld, toch? En is er nu een device dat u aan wilt melden?
Als dat het geval is stel ik voor dat u een Join Request aanmaakt en mij een sein geeft zodra dat gebeurt is. Ik kan dan direct checken of deze Join goed doorkomt en ervoor zorgen dat die verder verwerkt wordt.
Bedankt voor uw gegevens!
Ik ben in de Portal op zoek gegaan naar uw account en ik zie nu 4 geregistreerde devices naar voren komen. Daarvan zijn er als het goed is 2 (DevEUI eindigend op B6A & B6B) via OTAA aangemeld, toch? En is er nu een device dat u aan wilt melden?
Als dat het geval is stel ik voor dat u een Join Request aanmaakt en mij een sein geeft zodra dat gebeurt is. Ik kan dan direct checken of deze Join goed doorkomt en ervoor zorgen dat die verder verwerkt wordt.
Hi @Rick S.
Ik probeer device deveui ...B6B, pratend te krijgen via OTAA. Dit apparaat probeert op dit moment de 'over the air activation' uit te voeren.
Ik probeer device deveui ...B6B, pratend te krijgen via OTAA. Dit apparaat probeert op dit moment de 'over the air activation' uit te voeren.
Reputatie 7
+6
Goedemiddag @Ruben ,
Bedankt voor uw bericht!
Zullen we anders met dit device een nieuwe start maken?
Dan verwijder ik dit device eerst van de portal en geef ik u een sein. Vervolgens kunt u een nieuw Join Request aanmaken en volgen we dat stap voor stap. Het device staat nu namelijk als 'Activated' op de portal, dus een Join Request heeft nu geen zin.
Zal ik het device eerst van de portal verwijderen?
Bedankt voor uw bericht!
Zullen we anders met dit device een nieuwe start maken?
Dan verwijder ik dit device eerst van de portal en geef ik u een sein. Vervolgens kunt u een nieuw Join Request aanmaken en volgen we dat stap voor stap. Het device staat nu namelijk als 'Activated' op de portal, dus een Join Request heeft nu geen zin.
Zal ik het device eerst van de portal verwijderen?
Dat is goed,.
"Het device staat nu namelijk als 'Activated' op de portal, dus een Join Request heeft nu geen zin. "
zou je voor mijn beeldvoorming dit toe kunnen lichten? Stuurt de portal geen JoinAccept meer als het apparaat eenmaal 'activated' is ofzo?
Reputatie 7
+6
Hi Ruben,
Het device is nu van de portal verwijderd. Geeft u een gil als er een Join Request is aangemaakt?
Als er een Join Request aangemaakt wordt voor een device dat al aangemeld is wordt de Join voor zover ik weet geweigerd.
Het device is nu van de portal verwijderd. Geeft u een gil als er een Join Request is aangemaakt?
Als er een Join Request aangemaakt wordt voor een device dat al aangemeld is wordt de Join voor zover ik weet geweigerd.
Ik heb mijn device aangezet, er zou dus nu een join request binnen moeten komen.
"Als er een Join Request aangemaakt wordt voor een device dat al aangemeld is wordt de Join voor zover ik weet geweigerd."
Dat zou wel een beetje raar zijn. Want als een device gereset zou worden terwijl deze al een keer geactiveerd was. Dan vergeet de device de keys, en moet deze opnieuw een join request doen. Maar de portal weet niet dat de device gereset is. Dus als de device dan een joinRequest stuurt, dan zou de portal dit weigeren. en dus dan kan je je apparaat nooit meer opnieuw aanmelden op het netwerk. Of zie ik nu iets over het hoofd?
"Als er een Join Request aangemaakt wordt voor een device dat al aangemeld is wordt de Join voor zover ik weet geweigerd."
Dat zou wel een beetje raar zijn. Want als een device gereset zou worden terwijl deze al een keer geactiveerd was. Dan vergeet de device de keys, en moet deze opnieuw een join request doen. Maar de portal weet niet dat de device gereset is. Dus als de device dan een joinRequest stuurt, dan zou de portal dit weigeren. en dus dan kan je je apparaat nooit meer opnieuw aanmelden op het netwerk. Of zie ik nu iets over het hoofd?
Mijn device is zojuist in de " MLME-Confirm" functie vast gelopen. Maar omdat ik daar geen breakpoint had staan. Kon ik niet achterhalen wat deze error veroorzaakt had. Ik heb nu een breakpoint geplaatst en het apparaat gereset.
Maar het feit dat de MLME-Confirm functie aangeroepen werd is al goed nieuws. Nu heb ik het apparaat dus gereset en hoop nu de error te kunnen herproduceren. Ik weet alleen niet of het device al geactiveerd was voor 15:47.
en zou de device nog een keer van de portal verwijderd kunnen worden?
Reputatie 7
+6
Hi Ruben,
Nog even snel voordat ik richting een afspraak moet!
Ik begin inderdaad nu ook steeds meer aan mijn antwoord over de weigering te twijfelen. Ik ga dit voor de zekerheid even navragen. En natuurlijk kan ik het device nogmaals van de portal verwijderen. Ik zie hem alleen nog niet terug. En hij staat ook niet in de lijst met 'To be activated OTAA devices'.
Nog even snel voordat ik richting een afspraak moet!
Ik begin inderdaad nu ook steeds meer aan mijn antwoord over de weigering te twijfelen. Ik ga dit voor de zekerheid even navragen. En natuurlijk kan ik het device nogmaals van de portal verwijderen. Ik zie hem alleen nog niet terug. En hij staat ook niet in de lijst met 'To be activated OTAA devices'.
Reputatie 7
+6
Goedemiddag @Ruben ,
Zoals besproken heb ik even bij de specialisten nagevraagd wat er gebeurt als er een nieuw Join Request wordt gedaan terwijl het device al op het netwerk aangemeld is.
Bij een normale join procedure wordt dus een MAC commando vanuit het device verzonden om een uitwisseling te doen van keys en DevAddr. Als een device gedurende haar levensduur een nieuwe Join Request verstuurt, wordt dit wel eens een re-join genoemd. Wat er echter gebeurt is exact dezelfde procedure als bij de initiële join procedure, zoals beschreven in Over the air activation of devices .
Om te voorkomen dat een ongeoorloofde imitatie plaatsvindt van de join procedure werkt het KPN netwerk met een logisch gecalculeerde AppNonce (in LoRaWAN specificaties v1.1 is dit JoinNonce) en DevNonce, waarmee wordt geverifieerd of het wel een geoorloofde volgende 're-join' is op het netwerk.
Het is dus correct dat het device zich opnieuw kan aanmelden op het netwerk bij het opnieuw uitvoeren van een join, maar alleen als het device dit doet met een nieuwe DevNonce, conform LoRaWAN 1.0 specificaties. Bij implementatie van de nieuwere LoRaWAN specificaties is het daar bovenop zo dat het device niet alleen een nieuwe (en random gegenereerde) DevNonce moet creëren, maar dat dit ook nog een logisch berekende DevNonce is, om te kunnen verifiëren dat deze nieuwe Join van het originele device afkomstig is.
Om in te gaan op het aspect ‘vergeten van keys bij een reset’: een device op het LoRa netwerk dient altijd de keys opgeslagen te hebben in het device zodra deze ontvangen zijn middels de OTAA procedure, ook al gaat het device van de spanning af. Een device zou alleen een nieuwe join moeten doen als dit noodzakelijk of voorgeschreven is. Het vaak resetten van een device en het herhaaldelijk uitvoeren van een nieuwe join zorgt er alleen maar voor dat het device veel vatbaarder is voor ‘identiteitsfraude’ van het device en dat werkt tegen de intentie van dit hele protocol in. Het is dus correct dat het device zich opnieuw kan aanmelden op het netwerk bij het opnieuw uitvoeren van een join, maar alleen als het device dit doet met een nieuwe DevNonce, conform LoRaWAN 1.0 specificaties. Bij implementatie van de nieuwere LoRaWAN specificaties is het daar bovenop zo dat het device niet alleen een nieuwe (en random gegenereerde) DevNonce moet creëren, maar dat dit ook nog een logisch berekende DevNonce is, om te kunnen verifiëren dat deze nieuwe join van het originele device afkomstig is.
Zoals besproken heb ik even bij de specialisten nagevraagd wat er gebeurt als er een nieuw Join Request wordt gedaan terwijl het device al op het netwerk aangemeld is.
Bij een normale join procedure wordt dus een MAC commando vanuit het device verzonden om een uitwisseling te doen van keys en DevAddr. Als een device gedurende haar levensduur een nieuwe Join Request verstuurt, wordt dit wel eens een re-join genoemd. Wat er echter gebeurt is exact dezelfde procedure als bij de initiële join procedure, zoals beschreven in Over the air activation of devices .
Om te voorkomen dat een ongeoorloofde imitatie plaatsvindt van de join procedure werkt het KPN netwerk met een logisch gecalculeerde AppNonce (in LoRaWAN specificaties v1.1 is dit JoinNonce) en DevNonce, waarmee wordt geverifieerd of het wel een geoorloofde volgende 're-join' is op het netwerk.
Het is dus correct dat het device zich opnieuw kan aanmelden op het netwerk bij het opnieuw uitvoeren van een join, maar alleen als het device dit doet met een nieuwe DevNonce, conform LoRaWAN 1.0 specificaties. Bij implementatie van de nieuwere LoRaWAN specificaties is het daar bovenop zo dat het device niet alleen een nieuwe (en random gegenereerde) DevNonce moet creëren, maar dat dit ook nog een logisch berekende DevNonce is, om te kunnen verifiëren dat deze nieuwe Join van het originele device afkomstig is.
Om in te gaan op het aspect ‘vergeten van keys bij een reset’: een device op het LoRa netwerk dient altijd de keys opgeslagen te hebben in het device zodra deze ontvangen zijn middels de OTAA procedure, ook al gaat het device van de spanning af. Een device zou alleen een nieuwe join moeten doen als dit noodzakelijk of voorgeschreven is. Het vaak resetten van een device en het herhaaldelijk uitvoeren van een nieuwe join zorgt er alleen maar voor dat het device veel vatbaarder is voor ‘identiteitsfraude’ van het device en dat werkt tegen de intentie van dit hele protocol in. Het is dus correct dat het device zich opnieuw kan aanmelden op het netwerk bij het opnieuw uitvoeren van een join, maar alleen als het device dit doet met een nieuwe DevNonce, conform LoRaWAN 1.0 specificaties. Bij implementatie van de nieuwere LoRaWAN specificaties is het daar bovenop zo dat het device niet alleen een nieuwe (en random gegenereerde) DevNonce moet creëren, maar dat dit ook nog een logisch berekende DevNonce is, om te kunnen verifiëren dat deze nieuwe join van het originele device afkomstig is.
"Een device zou alleen een nieuwe join moeten doen als dit noodzakelijk of voorgeschreven is. Het vaak resetten van een device en het herhaaldelijk uitvoeren van een nieuwe join zorgt er alleen maar voor dat het device veel vatbaarder is voor ‘identiteitsfraude’ van het device en dat werkt tegen de intentie van dit hele protocol in. "
Ik had juist precies het omgekeerde in mijn hoofd zitten: Ik weet niet meer wat de bron was, maar voor zover ik wist moest je juist eens in de zoveel tijd de keys vernieuwen (aka een (re) join request). Dit zou dan juist de veiligheid verhogen! Maar het zou ook goed kunnen dat ik dat verkeerd onthouden heb.
Op het moment probeer ik de, in mij vorige gestuurde bericht benoemde, bug in " MLME-Confirm" te fixen. Maar deze is lastig te traceren. Maar ik verwacht dat dat probleem de oorzaak is waarom de activering niet werkt.
Ik weet ondertussen wel dat het niets te maken heeft met pakketten die ik van jullie (kpn) terug krijg. Ik krijg de foutmelding namelijk ook als mijn device nog niets ontvangen heeft.
Als ik deze bug gefixt heb, ga ik nog eens proberen het apparaat te activeren.
Ik had juist precies het omgekeerde in mijn hoofd zitten: Ik weet niet meer wat de bron was, maar voor zover ik wist moest je juist eens in de zoveel tijd de keys vernieuwen (aka een (re) join request). Dit zou dan juist de veiligheid verhogen! Maar het zou ook goed kunnen dat ik dat verkeerd onthouden heb.
Op het moment probeer ik de, in mij vorige gestuurde bericht benoemde, bug in " MLME-Confirm" te fixen. Maar deze is lastig te traceren. Maar ik verwacht dat dat probleem de oorzaak is waarom de activering niet werkt.
Ik weet ondertussen wel dat het niets te maken heeft met pakketten die ik van jullie (kpn) terug krijg. Ik krijg de foutmelding namelijk ook als mijn device nog niets ontvangen heeft.
Als ik deze bug gefixt heb, ga ik nog eens proberen het apparaat te activeren.
Reageer
Meld je aan
Heb je al een account? Inloggen
Welkom
Nog geen account? Maak een account aan
Inloggen of registreren met sociaal netwerk
Inloggen met Facebook Login with LinkedInof
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
