[riot-devel] at86rf2xx and PHR filtering
Axel.Wachtler at atmel.com
Fri Apr 1 12:04:40 CEST 2016
What I did mean, there are various reasons, why a frame can be invalid.
The reserved PHR bit is one thing, invalid CRC another. The CRC calculation
inside the transceivers is done without the reserved PHR bit, the PHR value
is not part of the CRC itself.
For RX_AACK: I would suggest not trying to be a software nanny for the hardware,
e.g. not trying to track the *_BUSY states. (this is just an temporary/transient information
and when you receive this information in SW, it might already be outdated)
The state change commands in RF23x are queued commands (except FORCE_TRX_OFF, FORCE_PLL_ON)
That means any ongoing transaction is completed before the next command is effective
(transaction = receiving or tranmistting a frame).
E.g. if you are in BUSY_RX and you write CMD_PLL_ON, at first the entire frame received and after it,
the TRX switches to PLL_ON.
In all basic RX and TX states, including TX_ARET_ON, a transaction ends with a TRX_END IRQ.
This is not true for RX_AACK, reasons for this are: either a CRC error or address match error
(see address filtering in DS). This means that in case of a max length
frame the TRX stays in BUSY_RX_AACK for 4.xms before it switches back to RX_AACK_ON.
To end RX_AACK use either CMD_TRX_OFF or CMD_PLL_ON and wait until the desired state is reached
or one of the FORCE_commands if you need the transceiver immediately to stop the ongoing transaction
(e.g. when a Beacon needs to be sent)
Best Regards, Axel
> -----Original Message-----
> From: devel [mailto:devel-bounces at riot-os.org] On Behalf Of Alexander Aring
> Sent: Freitag, 1. April 2016 11:39
> To: RIOT OS kernel developers <devel at riot-os.org>
> Subject: Re: [riot-devel] at86rf2xx and PHR filtering
> 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
> 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 .
> - Alex
>  http://lxr.free-
> devel mailing list
> devel at riot-os.org
More information about the devel