I am trying to register a device using RAK-7249. After going through logs I can see an error
stack_1 | 2019-11-16T12:20:41.138132754Z INFO Join not accepted dev_eui=506F980000001000 error=error:pkg/joinserver:dev_nonce_too_small (DevNonce is too small) grpc_method=HandleJoin grpc_service=ttn.lorawan.v3.NsJs join_eui=1111111111111111 namespace=joinserver request_id=01DST2GZHF3T5H0EQJFS9TFHMR
But, while going through packet logger inside the gateway I can see below-mentioned join request payload
“JoinRequest”: {
“AppEUI”: "11 11 11 11 11 11 11 11 ",
“DevEUI”: "50 6F 98 00 00 00 10 00 ",
“DevNonce”: “71BD”
},
This device is a C class device and I am using
MAC Version 1.0.3
PHY version 1.0.3A
Support for C class devices in enabled
It looks like you are using a LoRaWAN stack that is embedded on the device and not TTN. On this forum we provide support for the TTN community network and not for local LoRaWAN stacks.
(Your mention of class C suggests you are not using TTN as well because TTN does not support class C on the community network)
I suggest you try either the vendors website or check which LoRaWAN server is embedded in the device and try its support forum.
If my conclusion is wrong and you are using TTN / TTN software please provide more details regarding your setup. The gateway does nothing apart from forwarding LoRaWAN packets to a back-end (which might run on the gateway for a private network), so in that case provide some information regarding the back-end you are using and its configuration.
To clarify, you are using the TTN server software stack, but in a private instance rather than using TTN itself. (You are also using a newer version than is currently running the TTN network, though it is unclear if that, or your desire for class C, etc is actually yet relevant)
Your issue however seems to be a fairly simple one - probably as a result of restarting your node, you have sent an invalid dev nonce.
Examining the code:
You will see that this error is generated if a dev nonce is sent which is smaller than one that has ever been heard for that device in the past. Naturally, clearing the history momentarily resolved that, but the problem is likely to repeat.
LMiC for example, likes to grab a random number as a dev nonce on startup, and then keep incrementing it until success. If you then restart it, and it grabs a smaller random number than it did last time, it’s easy to see why this would result in failure against that particular enforcement algorithm.
Even if you are not using LMiC, the relatively large number 0x71bd suggests your node is similarly “rolling the dice” with little regard for previously used values.
To really be spec-compliant, a node must keep track of the dev nonce used in all previous power sessions. That’s not dissimilar from the need to keep track of the previously used frame count within a join session, or when using ABP - people jump to OTAA thinking it will solve the need for persistent storage on the node when all it really does is move the problem. That said, because joins should be rare, recording used join nonces should be an orders of magnitude lower toll on an EEPROM than constantly recording the frame count would be.
As for your node not accepting the join until some specific condition is met, that sounds like a problem with the receive settings or receive window timing - for example, you may be getting things wrong for join RX1 and only succeeding in join RX2. Or erratic timing may mean success is simply somewhat random. Your log doesn’t seem to actually show a success - which would be expected to be a situation where after a join accept, the node started transmitting ordinary packets rather than join ones.
