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

[Thomas Eichinger]

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 :

Hi,

On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:

2017-05-17 17:47 GMT+02:00 Thomas Eichinger :

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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel




--
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org

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

[Baptiste Clenet]

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

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.

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?


2017-05-17 21:26 GMT+02:00 Alexander Aring :
> Hi,
>
> On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
>> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger :
>> > 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@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



-- 
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Alexander Aring]

Hi,

On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger :
> > 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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Baptiste Clenet]

2017-05-17 17:47 GMT+02:00 Thomas Eichinger :
> 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

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).

>
> Personally, I never tried what happens if you remove this check for 127-2
> and
> fully fill the frame buffer but I would imagine that exactly that happens,
> the
> last two bytes are overwritten by the FCS and thus lost, unless it already
> was
> the exact same checksum.
>
> Best, Thomas
>
>
>>
>>
>> 2017-05-16 16:42 GMT+02:00 Thomas Eichinger :
>>>
>>> Hi Baptiste,
>>>
>>> If you take a look at figures 37-1 and 37-2 in the data sheet you linked
>>> you can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this
>>> includes the FCS.
>>> So if the driver would allow writing 127 bytes into the frame buffer the
>>> last two bytes would indeed be overwritten which is undesired I guess.
>>>
>>> I hope I understood you correctly and this helps.
>>>
>>> Best, Thomas
>>>
 On May 16, 2017, at 6:09 AM, Baptiste Clenet 
 wrote:

 Thomas, Hauke, Martine, Kaspar what do you think about it?

 My last question: how do I send a packet with length 127 octets with
 at86rf2xx transceiver?

 2017-05-15 14:59 GMT+02:00 Baptiste Clenet :
>
> Hi,
>
> When I want to send a pkt which is 126 Octet long, I get a message
> from [at86rf2xx]:
> [at86rf2xx] error: packet too large (2 byte) to be send
>
> IEE802.15.4 MAX length is 127 so it should be sent.
> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame
> length */
>
> I checked source code of at86rf2xx driver and I think I understand the
> magic number +2 in the if condition but I don't know why this is
> checked.
>
> at86rf2xx_netdev.c:110:
>
>/* current packet data + FCS too long */
>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
> send (iov_len %d, i %d, count %d)\n",
>  (unsigned)len + 2, ptr->iov_len, i, count);
>return -EOVERFLOW;
>}
>
> +2 mean two FCS octets?
> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>
> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
> is calculated on the first N-2 octets in the Frame Buffer, and the
> resulting FCS field is transmitted in place of the last two octets
> from the Frame Buffer.
> 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.
>
> So while I think we should remove the +2 test and let the possibility
> to send packet up to 127 octets and I don't 

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

[Thomas Eichinger]

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.

Personally, I never tried what happens if you remove this check for 
127-2 and
fully fill the frame buffer but I would imagine that exactly that 
happens, the
last two bytes are overwritten by the FCS and thus lost, unless it 
already was

the exact same checksum.

Best, Thomas




2017-05-16 16:42 GMT+02:00 Thomas Eichinger :

Hi Baptiste,

If you take a look at figures 37-1 and 37-2 in the data sheet you 
linked you can see that IEEE 802.15.4 allows up to 127 bytes for the 
MPDU and this includes the FCS.
So if the driver would allow writing 127 bytes into the frame buffer 
the last two bytes would indeed be overwritten which is undesired I 
guess.


I hope I understood you correctly and this helps.

Best, Thomas

On May 16, 2017, at 6:09 AM, Baptiste Clenet  
wrote:


Thomas, Hauke, Martine, Kaspar what do you think about it?

My last question: how do I send a packet with length 127 octets with
at86rf2xx transceiver?

2017-05-15 14:59 GMT+02:00 Baptiste Clenet :

Hi,

When I want to send a pkt which is 126 Octet long, I get a message
from [at86rf2xx]:
[at86rf2xx] error: packet too large (2 byte) to be send

IEE802.15.4 MAX length is 127 so it should be sent.
#define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame 
length */


I checked source code of at86rf2xx driver and I think I understand 
the

magic number +2 in the if condition but I don't know why this is
checked.

at86rf2xx_netdev.c:110:

   /* current packet data + FCS too long */
   if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
   DEBUG("[at86rf2xx] error: packet too large (%u byte) to 
be

send (iov_len %d, i %d, count %d)\n",
 (unsigned)len + 2, ptr->iov_len, i, count);
   return -EOVERFLOW;
   }

+2 mean two FCS octets?
In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:

For a frame with a frame length specified as N (3 ≤ N ≤ 127), 
the FCS

is calculated on the first N-2 octets in the Frame Buffer, and the
resulting FCS field is transmitted in place of the last two octets
from the Frame Buffer.
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.

So while I think we should remove the +2 test and let the 
possibility

to send packet up to 127 octets and I don't understand the part in
datasheet: "the last two bytes are replaced by the internally
calculated FCS". This mean that a part of data is erased? (for 5
octets or 127)

Cheers,

[1] 
http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf



--
Baptiste




--
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel




--
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Baptiste Clenet]

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?


2017-05-16 16:42 GMT+02:00 Thomas Eichinger :
> Hi Baptiste,
>
> If you take a look at figures 37-1 and 37-2 in the data sheet you linked you 
> can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this 
> includes the FCS.
> So if the driver would allow writing 127 bytes into the frame buffer the last 
> two bytes would indeed be overwritten which is undesired I guess.
>
> I hope I understood you correctly and this helps.
>
> Best, Thomas
>
>> On May 16, 2017, at 6:09 AM, Baptiste Clenet  wrote:
>>
>> Thomas, Hauke, Martine, Kaspar what do you think about it?
>>
>> My last question: how do I send a packet with length 127 octets with
>> at86rf2xx transceiver?
>>
>> 2017-05-15 14:59 GMT+02:00 Baptiste Clenet :
>>> Hi,
>>>
>>> When I want to send a pkt which is 126 Octet long, I get a message
>>> from [at86rf2xx]:
>>> [at86rf2xx] error: packet too large (2 byte) to be send
>>>
>>> IEE802.15.4 MAX length is 127 so it should be sent.
>>> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>>>
>>> I checked source code of at86rf2xx driver and I think I understand the
>>> magic number +2 in the if condition but I don't know why this is
>>> checked.
>>>
>>> at86rf2xx_netdev.c:110:
>>>
>>>/* current packet data + FCS too long */
>>>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>>>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
>>> send (iov_len %d, i %d, count %d)\n",
>>>  (unsigned)len + 2, ptr->iov_len, i, count);
>>>return -EOVERFLOW;
>>>}
>>>
>>> +2 mean two FCS octets?
>>> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>>>
>>> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
>>> is calculated on the first N-2 octets in the Frame Buffer, and the
>>> resulting FCS field is transmitted in place of the last two octets
>>> from the Frame Buffer.
>>> 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.
>>>
>>> So while I think we should remove the +2 test and let the possibility
>>> to send packet up to 127 octets and I don't understand the part in
>>> datasheet: "the last two bytes are replaced by the internally
>>> calculated FCS". This mean that a part of data is erased? (for 5
>>> octets or 127)
>>>
>>> Cheers,
>>>
>>> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>>>
>>>
>>> --
>>> Baptiste
>>
>>
>>
>> --
>> Baptiste
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



-- 
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Thomas Eichinger]

Hi Baptiste,

If you take a look at figures 37-1 and 37-2 in the data sheet you linked you 
can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this 
includes the FCS. 
So if the driver would allow writing 127 bytes into the frame buffer the last 
two bytes would indeed be overwritten which is undesired I guess. 

I hope I understood you correctly and this helps. 

Best, Thomas 

> On May 16, 2017, at 6:09 AM, Baptiste Clenet  wrote:
> 
> Thomas, Hauke, Martine, Kaspar what do you think about it?
> 
> My last question: how do I send a packet with length 127 octets with
> at86rf2xx transceiver?
> 
> 2017-05-15 14:59 GMT+02:00 Baptiste Clenet :
>> Hi,
>> 
>> When I want to send a pkt which is 126 Octet long, I get a message
>> from [at86rf2xx]:
>> [at86rf2xx] error: packet too large (2 byte) to be send
>> 
>> IEE802.15.4 MAX length is 127 so it should be sent.
>> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>> 
>> I checked source code of at86rf2xx driver and I think I understand the
>> magic number +2 in the if condition but I don't know why this is
>> checked.
>> 
>> at86rf2xx_netdev.c:110:
>> 
>>/* current packet data + FCS too long */
>>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
>> send (iov_len %d, i %d, count %d)\n",
>>  (unsigned)len + 2, ptr->iov_len, i, count);
>>return -EOVERFLOW;
>>}
>> 
>> +2 mean two FCS octets?
>> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>> 
>> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
>> is calculated on the first N-2 octets in the Frame Buffer, and the
>> resulting FCS field is transmitted in place of the last two octets
>> from the Frame Buffer.
>> 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.
>> 
>> So while I think we should remove the +2 test and let the possibility
>> to send packet up to 127 octets and I don't understand the part in
>> datasheet: "the last two bytes are replaced by the internally
>> calculated FCS". This mean that a part of data is erased? (for 5
>> octets or 127)
>> 
>> Cheers,
>> 
>> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>> 
>> 
>> --
>> Baptiste
> 
> 
> 
> -- 
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Baptiste Clenet]

Thomas, Hauke, Martine, Kaspar what do you think about it?

My last question: how do I send a packet with length 127 octets with
at86rf2xx transceiver?

2017-05-15 14:59 GMT+02:00 Baptiste Clenet :
> Hi,
>
> When I want to send a pkt which is 126 Octet long, I get a message
> from [at86rf2xx]:
> [at86rf2xx] error: packet too large (2 byte) to be send
>
> IEE802.15.4 MAX length is 127 so it should be sent.
> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>
> I checked source code of at86rf2xx driver and I think I understand the
> magic number +2 in the if condition but I don't know why this is
> checked.
>
> at86rf2xx_netdev.c:110:
>
> /* current packet data + FCS too long */
> if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
> DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
> send (iov_len %d, i %d, count %d)\n",
>   (unsigned)len + 2, ptr->iov_len, i, count);
> return -EOVERFLOW;
> }
>
> +2 mean two FCS octets?
> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>
> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
> is calculated on the first N-2 octets in the Frame Buffer, and the
> resulting FCS field is transmitted in place of the last two octets
> from the Frame Buffer.
> 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.
>
> So while I think we should remove the +2 test and let the possibility
> to send packet up to 127 octets and I don't understand the part in
> datasheet: "the last two bytes are replaced by the internally
> calculated FCS". This mean that a part of data is erased? (for 5
> octets or 127)
>
> Cheers,
>
> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>
>
> --
> Baptiste



-- 
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Baptiste Clenet]

Hi,

When I want to send a pkt which is 126 Octet long, I get a message
from [at86rf2xx]:
[at86rf2xx] error: packet too large (2 byte) to be send

IEE802.15.4 MAX length is 127 so it should be sent.
#define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */

I checked source code of at86rf2xx driver and I think I understand the
magic number +2 in the if condition but I don't know why this is
checked.

at86rf2xx_netdev.c:110:

/* current packet data + FCS too long */
if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
send (iov_len %d, i %d, count %d)\n",
  (unsigned)len + 2, ptr->iov_len, i, count);
return -EOVERFLOW;
}

+2 mean two FCS octets?
In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:

For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
is calculated on the first N-2 octets in the Frame Buffer, and the
resulting FCS field is transmitted in place of the last two octets
from the Frame Buffer.
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.

So while I think we should remove the +2 test and let the possibility
to send packet up to 127 octets and I don't understand the part in
datasheet: "the last two bytes are replaced by the internally
calculated FCS". This mean that a part of data is erased? (for 5
octets or 127)

Cheers,

[1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf


-- 
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel