at86rf2xx: Always set channel on device#9616
Conversation
This removes the check if the current configured channel equals the new channel. This check prevents the at86rf2xx channel to be configured after a reset which causes the radio to be non-functional after a NETOPT_STATE_RESET.
smlng
left a comment
There was a problem hiding this comment.
untested ACK (no hardware right now), but looks good.
|
This PR fixes the described issue after resetting the interface for the first time ( |
|
I'd have to investigate a bit more. For the moment I think we can conclude that this is only a partial fix. |
|
I can confirm the issue. Tested with Fun fact: I tested on master [too, and the issue is there as well], so this PR is not the problem. |
|
hence, my ACK holds - now a tested one. @PeterKietzmann you wanna file an issue, as you found it. |
|
I suspect that the issue fixed here is only one of the issues that causes problems after a reset. (One of) the other issues is that the flag set by NIB to use long addresses is cleared by the reset and not reapplied. |
|
interesting: after two resets the node does not respond to direct pings anymore but it does to pings on |
|
same issue on PhyNode (pba-d-01-kw2x) so its more general and also (very likely) not driver related but in a higher layer (or conceptual how radio drivers interact with higher layers). |
|
See #9656 and extend, if needed. |
|
When migrating the last Pull Requests for the release, I noticed this Due to the tests being now all run I would find it hard to backport it now. This also show that this should be integrated to one of the automated tests. |
RIOT-OS#9616 Issue was at the end not backported
RIOT-OS#9616 Issue was at the end not backported
RIOT-OS#9616 Issue was at the end not backported

Contribution description
This removes the check if the current configured channel equals the new
channel. This check prevents the at86rf2xx channel to be configured
after a reset which causes the radio to be non-functional after a
NETOPT_STATE_RESET.
Issues/PRs references
fixes #8118
Testing
Branch is intentionally not based on the latest master to prevent #9577/#9606 from causing issues.
The issue that causes gnrc_netif to switch to short source MAC addresses is not resolved here.