[riot-devel] at86rf2xx and PHR filtering

Alexander Aring alex.aring at gmail.com
Fri Apr 1 11:38:31 CEST 2016


Hi,

On Fri, Apr 01, 2016 at 09:17:02AM +0000, Wachtler, Axel wrote:
> Hi Alex,
> 
> weird things on air result mostly in a damaged CRC. However malicious frames can always
> generated by any SDR. My vote would be, because RIOT targets to 15.4 to drop any 
> invalid length frame early on PHY level and don't bother the upper layers to handle the junk. 
> (part of the junk handling is already done in RF23x HW, e.g. when RX_AACK drops invalid CRC 
> frames, or if the framefilter rejects frames with none matching addresses.)
> 

I think the PHR will not be part of CRC, also you cannot be sure that
CRC guarantees that the frame is correct received when the CRC is
correct.

I agree when the CRC is invalid then the PHR is maybe also broken,
that's why this issue is likely when going into promiscuous mode
(then crc in RX_AACK_ON will be ignored).

Let me imagine the following device which is build by a very bad
guy/girl:

Looking for preamble, then let length field in some reserved area and let
the mac frame looking okay, correct CRC, etc.

Then walk with such device on the next embedded world and have fun. ;-)
Reminds me about the TV-B-Gone remote control.

But I think when the len is above 127, then I don't know which field
will be used by at86rf2xx for the CRC (?maybe the last two ones?).
I would need to check that at first. :-)


btw: when I talking right now with an atmel expert. Aother issue would
be the state-change assertion which is recommended by:

"AVR2022: AT86RF231 - Software Programming Model"

or some other Software Programming Model of at86rf2xx on site:

"Transitions to State RX_AACK_ON"

all state changes should be have an assertion to be sure if you are inside
the state which you wanted to change in before.

This doesn't work for RX_AACK_ON, because it could be that the assertion
will be done in the time between "change into RX_AACK_ON" and "received
SFD", then the transceiver will go into BUSY state and the assertion
will fail.

It's not a failure, I am happy that I am so fast in my implementation
that this race can occur. :-) But everybody should ignore the state
RX_BUSY while assertion when going into RX_AACK_ON. That's what we do
inside the Linux driver, see [0].

- Alex

[0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L413


More information about the devel mailing list