-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LoRaWAN] Fix channel logic: for fixed bands, persistence of dynamic bands, rejoining during active session #942
Conversation
Apologies for not delivering a bug-free experience on the previous version.. I hope it's much better now! |
Alright that were two more.. the setDatarate function accidentally had incorrect equality checks. And with the new key checksum & mode check, I accidentally wiped the DevNonce and JoinNonce as well which should not be discarded if the user just wants to refresh the session keys by doing a new join. That's now fixed and I'm officially out of things I would change for at least the next month unless some user finds a bug. |
Nope, still found an off-by-one mistake - your logging struct working wonders in finding these bugs! |
@StevenCellist no worries, haven't had the time to review anyway ;) |
@StevenCellist finally had the time to review - there's nothing that would prevent me from merging this, thank you very much for the continued support! I will also run the CI to build everything and 6.4.1 should get released in few hours from now. |
Short feedback for you (@StevenCellist / @jgromes), I tried a STM32WL55 module with the latest 6.4.1 patch, as well as with 6.4.0 and 6.3.0 in EU868 state with the LoRaWAN reference example. 6.3.0 - works flawlessly
Am I the issue? :)
|
@nmaas87 did you wipe between versions? (And reset on console) |
Yes @StevenCellist - I actually did not and on first tried restore of the "old" 6.3.0 session I got the error
However I read that the session structure had changed, so I did already think that would fail :). |
So you performed a node.wipe(), then did beginOTAA which returned -1106? What... It's literally worked like a charm on my device which is happily running under .1% dutycycle for five days straight now. You'll need to provide debug (not verbose) logs, maybe under separate Issue/Discussion, to see if it's something in the stack or on your side. Quick note that 6.3.0 did work on the surface but actually was not compliant if you'd squint with your eyes at the by now quite verbose debug output. V6.4.1 is the way to go but must work then of course. |
Thank you for your feeback, I opened up the appropriate issue report to get this worked the right way :) |
Under various situations the channel logic was not completely tight. Thanks to @jerryneedell for verifying and debugging fixed-band behavior in #935. This PR also fixes bugs on sessions with ADR disabled, as after restore, all channels were masked away. Moreover, rejoining on OTAA during an active session didn't clear the MAC command queue (they piled up) and remained stored channels in the availableChannels structure.
As of 6.4.0, only specific sessions work well (with ADR enabled or without restoring the session, without rejoining during active session). I would suggest a bugfix release to 6.4.1, although that's completely up to you. I have no idea what your policy is around this sort of stuff :)