Hi all,
The LoRaWAN 1.1 specification indicates that the Network Server must keep track and verify the DevNonce (Sect. 6.2.2, p. 52).
However, the Backend Interfaces v1.1.0 specification says that in case of invalid DevNonce, the Join Server sends a “FrameReplayed” error message to the Network Server (Sect. 8, p. 18). This implies that the Join Server verifies also the DevNonce.
Does the Join Server actually verify DevNonce (even though the specification does not say so)? Moreover, does the Join Server verify RJcount0 (the LoRaWAN 1.1 specification says that it must be verified by the Network Server (Sect. 6.2.4.1, p. 58))?
And does the Network Server verify the RJcount1 (the LoRaWAN 1.1 specification says that it must be verified by the Join Server (Sect. 6.2.4.2, p. 59))?
Thank you in advance for your answers.
Best regards
Hi @loicferreira,
I don’t know much about the Join Server stuff, my knowledge is limited to Network Servers. So hopefully someone else can answer for the DevNonce stuff.
I know that there is pretty much no support out there for Rejoin Requests. Chirpstack should have something implemented but then BasicStation doesn’t even forward Rejoin Requests as it thinks they are invalid frames. So I don’t think RJcount is in use anywhere.
As LoRaWAN v1.1 is going out of fashion next year and will be replaced by v1.2, there is little incentive to improve support for v1.1 as the major parties will aim for v1.2 instead.
Hi @stevencellist ,
LoRaWAN 1.2 makes use of DevNonce and RJcount counters. So the same questions apply to v1.2.
That said, is there any public announcement regarding the replacement of v1.1 by v1.2 next year?
Given that the Join Server generates the session keys (look up some pictures/schemes on Google), it has to know the DevNonce, JoinNonce, AppKey/NwkKey and for Rejoin Requests it uses RJCount in the key derivation. And apparently some implementations also verify these values?
There’s no public information yet about v1.2, work is ongoing, among which using just one RJCount instead of the current two.
Is v1.2 supposed to be compatible with v1.0.x (the same way v1.1 is backward compatible)? By compatible I mean the ability of an end-device implementing v1.1 to reverse to v1.0.x when it communicates with a Network Server implementing the latter version. Or maybe the other way around.
Keep in mind, work in progress…
End-devices which comply with this version of the specification SHOULD be capable of operating with Network Servers implementing version 1.0.4, to assist with backward compatibility. If an end-device implements an earlier version than 1.2.0, that version SHALL be 1.0.4.