JoinRequest and JoinAccept Loop fix and question

1

After successfully connecting to the ThingsNetwork (TTN) server on both the UG56 and UG63 gateways with my LoRa E5 dev board, I then redirected the packet forwarder of both UG56 and UG63 gateways to ChirpStack. However, I got stuck in a JoinAccept and JoinRequest loop. I fixed this by performing a full chip erase on the LoRa E5 dev board and deleting the DevNonce in the PostgreSQL database of the ChirpStack NS, after which I was able to successfully connect to ChirpStack. But when I tried to reconnect to TTN, TTN still accepted the OTAA of all my devices, even though I still had all the keys on ChirpStack that I hadn’t deleted.

If TTN has an automatic mechanism to reset the keys to accept connections after I successfully connected to ChirpStack in the past, then why, after successfully connecting the devices to the embedded Network Server on UG56, am I unable to reconnect to either TTN or ChirpStack? Why do I have to perform a full chip erase again to be able to reconnect to both TTN and ChirpStack after successfully connecting to the embedded Network Server on UG56?

What reason could be ?

cssaup
cssaup1580×317 43.1 KB

chipup
chipup1605×313 15.8 KB

2

The Nonces are a security implementation to prevent someone from hijacking your ‘credentials’, as the DevNonce can only ever be increasing (and if they were to use a lower value, it is rejected as you notice). So while they certainly can, TTN and Chirpstack (and all other LNS) implementing LW v1.0.4 &/ v1.1 follow the LoRa-Alliance rules rejecting Nonces that are too low.