Re: [riot-devel] Setting options in an IEEE 802.15.4 driver

[Aaron Sowry]

Yes, it is working, it's just a bit confusing for someone looking at
the code. Anyhow let's continue the discussion on the PR.

Thanks,
Aaron

2016-04-02 1:05 GMT+13:00 Martine Lenders :
> Hi,
> regardless, I opened a PR to fix it:
> https://github.com/RIOT-OS/RIOT/pull/5227
>
> Cheers,
> Martine
>
> 2016-04-01 13:59 GMT+02:00 Martine Lenders :
>>
>> Hi,
>> just tested the behavior with `examples/default` and setting the short
>> address is working, so it might be a bit messy implemented (mostly because
>> `netdev2_ieee802154_set()` was introduced later in the process), but it IS
>> working.
>>
>> Cheers,
>> Martine
>>
>> 2016-04-01 6:55 GMT+02:00 Aaron Sowry :
>>>
>>> Actually, I don't think netdev2_ieee802154_set() will ever be called
>>> from _set(), since the check to call this is 'if (res == -ENOTSUP)'.
>>> 'res' is set to '0' before the case statement and never changed in the
>>> case of NETOPT_ADDRESS, so I guess the only reason it works at all is
>>> because the device struct's 'short_addr' is being set (incorrectly?)
>>> by at86rf2xx_set_addr_short()?
>>>
>>> /Aaron
>>>
>>> 2016-04-01 16:27 GMT+13:00 Aaron Sowry :
>>> > Hi,
>>> >
>>> > I'm currently working on an 802.15.4 driver, and trying to use all the
>>> > fancy new boilerplate functionality which was merged recently. I'm
>>> > using the at86rf2xx driver as inspiration, but the way it sets some
>>> > options (e.g. the long and short addresses) confuses me a bit.
>>> >
>>> > The at86rf2xx's netdev set() function, when called with
>>> > NETOPT_ADDRESS, will call at86rf2xx_set_addr_short() which sets the
>>> > short_addr of the device struct along with some other
>>> > at86rf2xx-specific stuff. At the end of the case statement, however,
>>> > it then calls netdev2_ieee802154_set() *as well*, which appears to do
>>> > the same thing again (minus the chip-specific stuff).
>>> >
>>> > Perhaps I'm getting lost in a forest of extended structs, but is this
>>> > intentional? It seems like at86rf2xx_set_addr_short() should *only* be
>>> > doing the chip-specific stuff, and leaving the rest up to
>>> > netdev2_ieee802154_set()? I hope my description's not too hard to
>>> > follow.
>>> >
>>> > Cheers,
>>> > Aaron
>>> ___
>>> 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
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT-ESP8622

[Kaspar Schleiser]

Hey,

On 04/01/2016 06:11 PM, René Kijewski wrote:
> if someone (here in Berlin) wants to try their porting skills I could offer 
> hardware:
> 
>  - ESP-12E (http://www.ebay.com/itm/171907430053)
>  - ESP-201 (http://www.ebay.com/itm/181846574978)

There's a project for providing open source tools for it at [1].
Getting a basic port of the MCU running should be straight-forward, but
it looks like most of the actual WiFi code is closed-source.

Kaspar

[1] https://github.com/pfalcon/esp-open-sdk

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

Re: [riot-devel] RIOT-ESP8622

[René Kijewski]

Am Fri, 1 Apr 2016 17:56:38 +0200
schrieb Hauke Petersen :

> RIOT can certainly be ported to the ESP8622, and it would make for a 
> very interesting platform. I think some people (including myself) have 
> briefly looked into this, but there has been created no countable 
> output, yet.

Hi,

if someone (here in Berlin) wants to try their porting skills I could offer 
hardware:

 - ESP-12E (http://www.ebay.com/itm/171907430053)
 - ESP-201 (http://www.ebay.com/itm/181846574978)

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

Re: [riot-devel] RIOT-ESP8622

[Hauke Petersen]

Hi Roger,

RIOT can certainly be ported to the ESP8622, and it would make for a 
very interesting platform. I think some people (including myself) have 
briefly looked into this, but there has been created no countable 
output, yet. The main problem I have encountered so far is their custom 
CPU core. I have only found part of the information needed (ISA, stack 
handling, peripheral register descriptions) that is needed to port RIOT, 
but I have not looked very good for it...


Cheers,
Hauke


On 31.03.2016 13:19, Roger wrote:

Hi,

I'm wondering if RIOT can be used in combination with the ESP8622.

Thank you for considering my request

Best regards

- Roger Zink -


___
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

[riot-devel] RIOT-ESP8622

[Roger]

Hi,

I'm wondering if RIOT can be used in combination with the ESP8622.

Thank you for considering my request

Best regards

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

[riot-devel] Question about RIOT/tests/thread_msg

[OuyangJianwen]

Hello,

I am a new beginner to learn RIOT. I got some question when I run the 
"thread_msg" on board "SAMR21-xpro".

For the thread1, thread2 and thread3, they have the same priority. so when the 
thread3 is running, how can scheduler switch to the thread1.

I saw these in the API:
"In case of equal priorities, the threads are scheduled in a 
semi-cooperative fashion. That means that unless an interrupt happens, 
threads with the same priority will only switch due to voluntary or 
implicit context switches."
and
"Some functions that unblock another thread, e.g. msg_send() or mutex_unlock(), 
can cause a thread switch, if the target had a higher priority."

but here, all the three threads have the same priority, so according the rule, 
even there is msg_send(), the thread3 should not be blocked and run forever, 
but it doesn't.

Thanks for your time!

Regards,
Jianwen OUYANG


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

Re: [riot-devel] Setting options in an IEEE 802.15.4 driver

[Martine Lenders]

Hi,
regardless, I opened a PR to fix it:
https://github.com/RIOT-OS/RIOT/pull/5227

Cheers,
Martine

2016-04-01 13:59 GMT+02:00 Martine Lenders :

> Hi,
> just tested the behavior with `examples/default` and setting the short
> address is working, so it might be a bit messy implemented (mostly because
> `netdev2_ieee802154_set()` was introduced later in the process), but it IS
> working.
>
> Cheers,
> Martine
>
> 2016-04-01 6:55 GMT+02:00 Aaron Sowry :
>
>> Actually, I don't think netdev2_ieee802154_set() will ever be called
>> from _set(), since the check to call this is 'if (res == -ENOTSUP)'.
>> 'res' is set to '0' before the case statement and never changed in the
>> case of NETOPT_ADDRESS, so I guess the only reason it works at all is
>> because the device struct's 'short_addr' is being set (incorrectly?)
>> by at86rf2xx_set_addr_short()?
>>
>> /Aaron
>>
>> 2016-04-01 16:27 GMT+13:00 Aaron Sowry :
>> > Hi,
>> >
>> > I'm currently working on an 802.15.4 driver, and trying to use all the
>> > fancy new boilerplate functionality which was merged recently. I'm
>> > using the at86rf2xx driver as inspiration, but the way it sets some
>> > options (e.g. the long and short addresses) confuses me a bit.
>> >
>> > The at86rf2xx's netdev set() function, when called with
>> > NETOPT_ADDRESS, will call at86rf2xx_set_addr_short() which sets the
>> > short_addr of the device struct along with some other
>> > at86rf2xx-specific stuff. At the end of the case statement, however,
>> > it then calls netdev2_ieee802154_set() *as well*, which appears to do
>> > the same thing again (minus the chip-specific stuff).
>> >
>> > Perhaps I'm getting lost in a forest of extended structs, but is this
>> > intentional? It seems like at86rf2xx_set_addr_short() should *only* be
>> > doing the chip-specific stuff, and leaving the rest up to
>> > netdev2_ieee802154_set()? I hope my description's not too hard to
>> > follow.
>> >
>> > Cheers,
>> > Aaron
>> ___
>> 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] Setting options in an IEEE 802.15.4 driver

[Martine Lenders]

Hi,
just tested the behavior with `examples/default` and setting the short
address is working, so it might be a bit messy implemented (mostly because
`netdev2_ieee802154_set()` was introduced later in the process), but it IS
working.

Cheers,
Martine

2016-04-01 6:55 GMT+02:00 Aaron Sowry :

> Actually, I don't think netdev2_ieee802154_set() will ever be called
> from _set(), since the check to call this is 'if (res == -ENOTSUP)'.
> 'res' is set to '0' before the case statement and never changed in the
> case of NETOPT_ADDRESS, so I guess the only reason it works at all is
> because the device struct's 'short_addr' is being set (incorrectly?)
> by at86rf2xx_set_addr_short()?
>
> /Aaron
>
> 2016-04-01 16:27 GMT+13:00 Aaron Sowry :
> > Hi,
> >
> > I'm currently working on an 802.15.4 driver, and trying to use all the
> > fancy new boilerplate functionality which was merged recently. I'm
> > using the at86rf2xx driver as inspiration, but the way it sets some
> > options (e.g. the long and short addresses) confuses me a bit.
> >
> > The at86rf2xx's netdev set() function, when called with
> > NETOPT_ADDRESS, will call at86rf2xx_set_addr_short() which sets the
> > short_addr of the device struct along with some other
> > at86rf2xx-specific stuff. At the end of the case statement, however,
> > it then calls netdev2_ieee802154_set() *as well*, which appears to do
> > the same thing again (minus the chip-specific stuff).
> >
> > Perhaps I'm getting lost in a forest of extended structs, but is this
> > intentional? It seems like at86rf2xx_set_addr_short() should *only* be
> > doing the chip-specific stuff, and leaving the rest up to
> > netdev2_ieee802154_set()? I hope my description's not too hard to
> > follow.
> >
> > Cheers,
> > Aaron
> ___
> 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 and PHR filtering

[Alexander Aring]

On Fri, Apr 01, 2016 at 10:04:40AM +, Wachtler, Axel wrote:
> 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.
> 
> 

ok.

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

I looked now in RIOT code [0].

So they will call at86rf2xx_set_state(at86rf2xx_t *dev, uint8_t state)
with state as RX_AACK_ON, but at the end they call:

_set_state(at86rf2xx_t *dev, uint8_t state)

with RX_AACK_ON, so it could be that RIOT has this behaviour:

MCU   -> at86rf2xx_set_state(foo, RX_AACK_ON)
at86rf2xx -> going into RX_AACK_ON
at86rf2xx -> detected SFD, going into RX_AACK_BUSY
  MCU   -> _set_state(foo, RX_AACK_ON)
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> stucks inside 
this loop
at86rf2xx -> receiving done, going into RX_AACK_ON
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> loop ends


The stucking inside the loop for assertion is here a possible case which
is bad. But okay it's unlikely I also get such issues only when I make
really big traffic.

- Alex

[0] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_getset.c#L420
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx and PHR filtering

[Wachtler, Axel]

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-boun...@riot-os.org] On Behalf Of Alexander Aring
> Sent: Freitag, 1. April 2016 11:39
> To: RIOT OS kernel developers 
> Subject: Re: [riot-devel] at86rf2xx and PHR filtering
> 
> Hi,
> 
> On Fri, Apr 01, 2016 at 09:17:02AM +, 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
> ___
> 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 and PHR filtering

[Alexander Aring]

Hi,

On Fri, Apr 01, 2016 at 09:17:02AM +, 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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

On Fri, Apr 01, 2016 at 08:45:48AM +, Wachtler, Axel wrote:
> > Most datasheets doesn't say anything what they filter on PHR or not.
> 
> 
> 
> The MSB in the PHR field is reserved, see at86rf230 DS:
> 
> 
> 
> [cid:image001.png@01D18C02.AB62FEF0]
> 
> 
> 
> At and after RF231 this Bit could be sent by the transceiver and can then be 
> seen at the receiver site as well.
> 
> 
> 
> Also the standard tells that this bit is reserved, so proper implementations 
> needs to mask this out in order
> 
> to get the correct frame length at the receiving site.
> 

Okay, then all transceivers need to do that and mostly at driver layer
because at the tail are mostly LQI/RSSI information.

But it's not just the MSB bit, there are also some other "len" values
which are reserved:

256  *  0-4 Reserved
257  *  5   MPDU (Acknowledgment)
258  *  6-8 Reserved
259  *  9-127   MPDU


If you received one which is reserved then you know:

"It's an invalid 802.15.4 frame".

Question is how to react on that, already drop then on driver layer ->
because it's part of phy layer and not mac layer. Or simple do what we
do with deliver the full 127 byte frame to mac layer.

We assume then something weird happend on the air. :-)

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

Re: [riot-devel] at86rf2xx and PHR filtering

[Wachtler, Axel]

> Most datasheets doesn't say anything what they filter on PHR or not.



The MSB in the PHR field is reserved, see at86rf230 DS:



[cid:image001.png@01D18C02.AB62FEF0]



At and after RF231 this Bit could be sent by the transceiver and can then be 
seen at the receiver site as well.



Also the standard tells that this bit is reserved, so proper implementations 
needs to mask this out in order

to get the correct frame length at the receiving site.



Best Regards, Axel



> -Original Message-

> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Alexander Aring

> Sent: Freitag, 1. April 2016 10:31

> To: devel@riot-os.org

> Subject: [riot-devel] at86rf2xx and PHR filtering

>

> Hi,

>

> I recentely talked with another 6lowpan linux developer about an ugly

> behaviour of at86rf2xx transceivers and I told him I could break many of nodes

> which use them because nobody really care about that while programming.

>

> The issue is that the len byte inside the PHR will not filtered by the 
> at86rf2xx

> transceivers, so the length could be above 127. Also remember this can happen

> when the CRC is still correct. So I can mostly overwrite some stack space, 
> when

> the buffer is allocated on stack at first.

>

> Most datasheets doesn't say anything what they filter on PHR or not.

>

> In conclusion we introduce inside the Linux kernel [0] and all drivers will 
> check

> the length field when receiving at first.

>

> In case of at86rf230 driver we check the len field at first, if invalid then 
> we

> read out the full frame buffer (interesting for monitor interfaces and

> mac802154/etc should filter them correctly anyway if it's invalid), just avoid

> copying above 127 because array boundaries. See [1].

>

> btw: We read also the full framebuffer always because the RX_SAFE_MODE

> functionality from at86rf2xx transceivers. But then we check on a valid length

> field.

>

> The developer told me to tell that RIOT, so I just want to leave a note here 
> and I

> don't know if RIOT does filtering on that or not.

>

> - Alex

>

> [0] http://lxr.free-electrons.com/source/include/linux/ieee802154.h#L263

> [1] 
> http://lxr.free-

> electrons.com/source/drivers/net/ieee802154/at86rf230.c#L704

> ___

> 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

[riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

Hi,

I recentely talked with another 6lowpan linux developer about an ugly
behaviour of at86rf2xx transceivers and I told him I could break many of
nodes which use them because nobody really care about that while
programming.

The issue is that the len byte inside the PHR will not filtered by the
at86rf2xx transceivers, so the length could be above 127. Also remember
this can happen when the CRC is still correct. So I can mostly overwrite
some stack space, when the buffer is allocated on stack at first.

Most datasheets doesn't say anything what they filter on PHR or not.

In conclusion we introduce inside the Linux kernel [0] and all drivers
will check the length field when receiving at first.

In case of at86rf230 driver we check the len field at first, if invalid
then we read out the full frame buffer (interesting for monitor
interfaces and mac802154/etc should filter them correctly anyway if it's
invalid), just avoid copying above 127 because array boundaries. See [1].

btw: We read also the full framebuffer always because the RX_SAFE_MODE
functionality from at86rf2xx transceivers. But then we check on a valid
length field.

The developer told me to tell that RIOT, so I just want to leave a note
here and I don't know if RIOT does filtering on that or not.

- Alex

[0] http://lxr.free-electrons.com/source/include/linux/ieee802154.h#L263
[1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L704
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel