Open bergzand opened 5 years ago
On a second look, I think this problem only occurs with the short address, radios clear the first bit before setting it, to mark it as unicast. The netdev_ieee802154 layer doesn't clear this bit.
Maybe it would be better to return an error if we try to netdev::set a broadcast address as the link layer address?
After looking through the driver code, I see multiple issues with the ieee802.15.4 short address handling. The generic structure at the moment is that the set_short_addr
handler of every radio sets both the netdev::short_addr
and the register of radio. The handler doesn't set a return code, causing the generic netdev_ieee802154_set
to also handle the set call, setting the netdev::short_addr
a second time, without clearing the broadcast bit. The cc2538 is the only exception here, that one doesn't set the netdev::short_addr
member.
What is happening:
The cc2538 doesn't clear the broadcast bit, same for socket_zep.
netdev::short_addr
:Some radios only clear the broadcast bit in the netdev::short_addr
member, but not the value that is send to the radio. This results in somewhat correct behaviour where the netdev::short_addr
remains in sync with the value in the radio.
netdev::short_addr
:This results in a desync between the radio and the netdev struct due to the second write to the netdev::short_addr
member.
Maybe it would be better to return an error if we try to netdev::set a broadcast address as the link layer address?
For now I propose to at least ensure that the handling of the address is identical between the radios. In the future, having a sanity check in the set call somewhere is IMHO preferable
@bergzand do you plan on writing a fix for this issue?
@bergzand do you plan on writing a fix for this issue?
I kinda got stuck looking for a nice way to solve this issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
This should be an easy fix, right?
Description
Most, if not all, radios adjust the link layer address to force it to unicast. However, the netdev_ieee802154 doesn't adjust the address, causing a mismatch between what gnrc thinks the link layer address is and what the radio has configured as a link layer address.
Steps to reproduce the issue
On
examples/gnrc_networking
on a samr21-xpro use the shell to set the long address to something non-unicast such asFF:F0:FF:F1:FF:F2:FF:F3
.Expected results
The address is set to and displayed as
7F:F0:FF:F1:FF:F2:FF:F3
, to mark it as unicastActual results
ifconfig
shows the address asFF:F0:FF:F1:FF:F2:FF:F3
.Versions