[riot-devel] at86rf2xx: packet too large -> FCS check

Thomas Eichinger thomas at riot-os.org
Fri May 19 00:39:47 CEST 2017


Hi Baptiste,

On 17 May 2017, at 23:22 PDT(-0700), Baptiste Clenet wrote:

> I re-do my example again started at 0:
> Example:
> at86rf2xx_tx_load(dev, ptr->iov_base, length=5, 0);
> FCS is calculated on bytes 0, 1 and 2 and bytes 3 and 4 are replaced 
> by FCS
>
> at86rf2xx_tx_load(dev, ptr->iov_base, length=126, 0);
> FCS is calculated on bytes 0, to 123 and bytes 124 and 125 are 
> replaced by FCS

Just ran a test using the txtsnd command in the default example which 
sends raw 802.15.4 frames and I didn't see any of my payload overwritten 
by FCS bytes

>
> In your example Alexandre:
>> I think when the transmitter starts sending the FRAME -> going into
>> BUSY. The transceiver will make some:
>>
>> init_fcs();
>> for (b:each_bytes_to_tx) { <--- 127 - 2
>>        send(b);
>>        calc_fcs(b);
>> }
>> send_fcs(); <--- 2 bytes
>>
>> then you need to be sure you send 127 - 2 bytes out
>
> You send to the radio driver N bytes, then the transceiver calculates
> FCS on this N bytes and after sending these N bytes, send the
> calculated FCS. So you say that transmitter appends FCS to the given
> frame.

This is the expected behavior with AUTO_CRC on, yes.

> Now, I'm helping to port OpenThread on RIOT and OpenThread stack gives
> sometimes to the radio driver a frame of 126 bytes. My team asks them
> how is it possible:
> Their answer:
>> The IEEE 802.15.4 frame length includes the FCS bytes at the end of 
>> the frame.  The radio driver should simply update the last two bytes 
>> of the frame rather than extending it.
>
> If I understand well, RIOT stack does not include FCS in its
> ieee802154 layer and OpenThread stack includes it?
>
> Am I right?

You are right.

For using OpenThread with RIOT the quick fix would be giving the OT 
buffer to RIOT with the buffer length - 2.

Best, Thomas

>
>
> 2017-05-17 21:26 GMT+02:00 Alexander Aring <alex.aring at gmail.com>:
>> Hi,
>>
>> On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
>>> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger <thomas at riot-os.org>:
>>>> Hi Baptiste,
>>>>
>>>> On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
>>>>
>>>>> According to their example:
>>>>> Example:
>>>>> A frame transmission of length five with TX_AUTO_CRC_ON set, is
>>>>> started with a Frame Buffer write access of five bytes (the last 
>>>>> two
>>>>> bytes can be omitted). The first three bytes are used for FCS
>>>>> generation; the last two bytes are replaced by the internally
>>>>> calculated FCS.
>>>>>
>>>>> Even a five bytes frame would have its last two bytes overwritten. 
>>>>> Is
>>>>> my understanding correct?
>>>>> So I don't understand why the driver limits the frame length to 
>>>>> 127-2?
>>>>
>>>>
>>>> The at86rf2xx driver doesn't limit the *frame length* to 127-2 
>>>> octets
>>>> because the
>>>> FCS is part of the frame sent out. The driver just makes sure that 
>>>> no
>>>> payload
>>>> data is overwritten by the FCS.
>>>>
>>>> Every 802.15.4 frame has two bytes of FCS. So if we didn't use
>>>> TX_AUTO_CRC_ON
>>>> we would have to calculate the checksum in software and write it 
>>>> into the
>>>> frame buffer, appended to the header, sequence number, addresses 
>>>> and payload
>>>> we
>>>> want to send. All together (FCF + seq_num + addrs + payload + FCS) 
>>>> this can
>>>> be 127 bytes max.
>>>>
>>>> Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have 
>>>> to
>>>> calculate
>>>> the FCS, it's appended to the rest of the frame.
>>>
>>> I don't think it is appended to the frame but it really replace the
>>> last two bytes of the frame
>>> Example:
>>> at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
>>> FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced 
>>> by FCS
>>>
>>
>> starting here at 0 or 1? :S
>>
>> Replaced by FCS? I suppose this function loads frame into 
>> framebuffer,
>> the FCS isn't calculated there. See below.
>>
>>> at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
>>> FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are 
>>> replaced by FCS
>>>
>>> So the stack which give the frame should give a frame  2bytes longer
>>> to let the transceiver calculate the FCS.
>>> This is why IMO this check is useless.
>>>
>>> After reading more the datasheet, it's not clear because it is 
>>> written:
>>> On transmission the radio transceiver generates and appends the FCS
>>> bytes during the frame transmission. This
>>> behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
>>> (register 0x04, TRX_CTRL_1).
>>>
>>
>> I think when the transmitter starts sending the FRAME -> going into
>> BUSY. The transceiver will make some:
>>
>> init_fcs();
>> for (b:each_bytes_to_tx) { <--- 127 - 2
>>         send(b);
>>         calc_fcs(b);
>> }
>> send_fcs(); <--- 2 bytes
>>
>> then you need to be sure you send 127 - 2 bytes out. If you disable
>>
>> ---
>>
>> now if you disable AUTO_CRC then you can load 127 bytes into 
>> framebuffer
>> and hopefully last 2 bytes are FCS (or doesn't need to be, but then 
>> you
>> running out-of-spec).
>>
>> - Alex
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> -- 
> Baptiste
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel


More information about the devel mailing list