Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Dear IWPAN Team,

I’m not sure if you received my last mail because it get's declared as 
spam because of using HTML.
Maybe there is a Problem with the Attachment (I’ve upload it to Dropbox).

Original Mail:
We (university of applied since Munich) are developing a multi-sensor 
Sniffer for IEEE 802.15.4 Networks, basted on your Linux-WPAN and the 
AT86RF233 Chip (with the REB233-XPRO).
We connect the REB233-XPRO with a BeagleBone Black and implement the 
AT-REB233 chip as Network interface (via iwpan).
The Beaglebone (BBB) is with at AT-REB233 via a 1Mhz SPI connected.

The AT-REB is so configured, that after a frame has received it send a 
interrupt to the BBB with can then read out the Frame Buffer.
The connection with the BeagleBone Works fine, but sometimes the network 
interface reads corrupted date.  That package starts normal but after 
+/- 6 Byte the frame gets (at most) periodical byte sequence like (0xff 
0 x30 0xf0 0x00 | 0xff 0 x30 0xf0 0x00 | ….).

We could evaluate, that the packages get corrupt after following situation:
- AT-REB233 sends a first interrupt
- The BBB ask what kind of interrupt it is and starts reading the 
Framebuffer
- The AT-REB sends a second interrupt after about the sixed Byte of the 
Framebuffer. Since this second interrupt the content of the Frame Buffer 
is corrupt (detectable by the byte sequence).
After the BBB has read the (corrupt) framebuffer it starts a new read 
(because of the second interrupt signalized that there are new data 
available), usually this is a ACK.
Might it be possible that the AT-REB233 received a new Data-Frame and 
overwrite the current Framebuffer after receiving the new (ACK)Package ?
The AT86RF233 does have a Framebuffer Protection (Section 9.3 in the 
Datasheet of the AT86RF233) (Dynamic Frame Buffer Reg 0x0C bit: 7 
section 11.8 in the Datasheet) ore by setting PLL_ON in the TRX_STATE 
Register (Reg: 0x02 9.3.1)
But I do not see such a configuration. May I have overseen it?

I have a PCAP package and a Logic dump attached. The logic dump could be 
analysed with the SALEAE Logic Tool(https://www.saleae.com/downloads )
This errors could be seen e.g. at and sec. :
- 10.099
- 11.428
- 11.433
- 28.218
I would be very grateful if you can help us with this problem.

Attachment’s : 
https://www.dropbox.com/sh/3mj7o7vo8hsjp0j/AADHI__q4fqZ51S1Ib_yyrNja?dl=0
Best Regards
Sebastian Balz

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Fri, Jul 07, 2017 at 12:18:34PM +0200, Balz wrote:
> Dear IWPAN Team,
> 
> I’m not sure if you received my last mail because it get's declared as spam
> because of using HTML.
> Maybe there is a Problem with the Attachment (I’ve upload it to Dropbox).
> 

no, previous not. Now we received them.

> Original Mail:
> We (university of applied since Munich) are developing a multi-sensor
> Sniffer for IEEE 802.15.4 Networks, basted on your Linux-WPAN and the
> AT86RF233 Chip (with the REB233-XPRO).
> We connect the REB233-XPRO with a BeagleBone Black and implement the
> AT-REB233 chip as Network interface (via iwpan).
> The Beaglebone (BBB) is with at AT-REB233 via a 1Mhz SPI connected.
> 

I don't own this board, but I used openlabs board (rf233) with BeagleBone
already and with success. (without problems so far I noticed).

> The AT-REB is so configured, that after a frame has received it send a
> interrupt to the BBB with can then read out the Frame Buffer.
> The connection with the BeagleBone Works fine, but sometimes the network
> interface reads corrupted date.  That package starts normal but after +/- 6
> Byte the frame gets (at most) periodical byte sequence like (0xff 0 x30 0xf0
> 0x00 | 0xff 0 x30 0xf0 0x00 | ….).
> 

Can you provide dts entry? Maybe lower your spi clock but 1 Mhz should
be okay :-/ ... maybe it's actually too low, try to use 5-4 Mhz
(controller will round down the clock anyway) I expiered bad behaviours
with a low clock.

> We could evaluate, that the packages get corrupt after following situation:
> - AT-REB233 sends a first interrupt
> - The BBB ask what kind of interrupt it is and starts reading the
> Framebuffer
> - The AT-REB sends a second interrupt after about the sixed Byte of the
> Framebuffer. Since this second interrupt the content of the Frame Buffer is
> corrupt (detectable by the byte sequence).
> After the BBB has read the (corrupt) framebuffer it starts a new read
> (because of the second interrupt signalized that there are new data
> available), usually this is a ACK.
> Might it be possible that the AT-REB233 received a new Data-Frame and
> overwrite the current Framebuffer after receiving the new (ACK)Package ?
> The AT86RF233 does have a Framebuffer Protection (Section 9.3 in the
> Datasheet of the AT86RF233) (Dynamic Frame Buffer Reg 0x0C bit: 7 section
> 11.8 in the Datasheet) ore by setting PLL_ON in the TRX_STATE Register (Reg:
> 0x02 9.3.1)
> But I do not see such a configuration. May I have overseen it?
> 

We use them... See [0] and also the reason why we always read the _full_
frame buffer, because protection will lost after losing chip select when
start read frame command. [1]

> I have a PCAP package and a Logic dump attached. The logic dump could be
> analysed with the SALEAE Logic Tool(https://www.saleae.com/downloads )
> This errors could be seen e.g. at and sec. :
> - 10.099
> - 11.428
> - 11.433
> - 28.218
> I would be very grateful if you can help us with this problem.
>

If you see the error on the bus sounds like some framebuffer overwriting
issue sure... and lower/higher clock is unlikely that they fix your
issue..

I think I need more _important_ information:

- Kernel version (ti or mainline kernel?)

- cat /sys/kernel/debug/regmap/spi32766.0/registers

"spi32766.0" need to be changed to you spi controller name and mount
debugfs as well. Then you can check the current register settings on
your own as well.

- DTS entry section for AT86RF233 transceiver, you could change from
  level to edge triggered irqs (_maybe_? it will fix your issue, please
  provide if it fixed the issue then).

- You did the capture as monitor interface? (I think yes, otherwise you
  would not see ack frames)

- Alex

[0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L1404
[1] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L759

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

please keep mailinglist in cc.

On Sat, Jul 08, 2017 at 11:39:22AM +0200, Balz wrote:
> Hi Alex,
> 
> Thank you very mutch for you fast replay,
> 
> I've combined the openlabs DeviceTree fragment for rpi with the SPI-Dev
> Overlay from elinux:
> 
> /dts-v1/;
> 
> /plugin/;
> 
> / {
> 
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> 
> /* identification */
> 
> part-number = "spi0pinmux";
> 
> fragment@0 {
> 
> target = <&am33xx_pinmux>;
> 
> __overlay__ {
> 
> spi0_pins_s0: spi0_pins_s0 {
> 
> pinctrl-single,pins = <
> 
> 0x150 0x30/* spi0_sclk, INPUT_PULLUP | MODE0 */
> 
> 0x154 0x30/* spi0_d0, INPUT_PULLUP | MODE0 */
> 
> 0x158 0x10/* spi0_d1, OUTPUT_PULLUP | MODE0 */
> 
> 0x15c 0x10/* spi0_cs0, OUTPUT_PULLUP | MODE0 */
> 
> /* 0x044 0x17PWM - RESET*/
> 
> /* 0x1ac 0x27IRQ*/
> 
> /* 0x1a4 0x27SLP-Trigger*/
> 

why is this commented?

> > ;
> 
> };
> 
> };
> 
> };
> 
> fragment@1 {
> 
> target = <&spi0>;
> 
> __overlay__ {
> 
> #address-cells = <1>;
> 
> #size-cells = <0>;
> 
> status = "okay";
> 
> pinctrl-names = "default";
> 
> pinctrl-0 = <&spi0_pins_s0>;
> 
> spidev@0 {
> 
> spi-max-frequency = <24000000>;
> 
> reg = <0>;
> 
> compatible = "linux,spidev";
> 
> };
>

remove the spidev entry. This is for userspace /dev/spi0 device and the
bus is already used by at86rf230. OR you use different chipselects and
you have two devices on one spi bus. (Then it makes sense, but one of
them should be reg = <1>; then. If it makes sense - I don't know, I
think this is just for making board config more readable. Linux will
ignore reg <1>. Or maybe not?)

Also I don't know what happens with the multiple max freq stuff.

> at86rf233@0 {
> 
> compatible = "atmel,at86rf233";
> 
> reg = <0>;
> 
> interrupts = <14 4>;
> 
> interrupt-parent = <&gpio0>;
> 
> reset-gpio = <&gpio1 17 1>;
> 
> sleep-gpio = <&gpio3 19 1>;
> 
> spi-max-frequency = <3000000>;
> 
> xtal-trim = /bits/ 8 <0x0F>;
> 
> };
> 
> };
> 
> };
> 
> };
> 

I googled for my valid spi configuration. _IMPORTANT_ i don't know if I
used the same SPI interface which you used. See [0].

> The Registers a configured as:
> 
> cat /sys/kernel/debug/regmap/spi1.0/registers
> 
> 01: 16
> 02: 16
> 03: 00
> 04: 20
> 05: 00
> 06: 20
> 07: ff
> 08: 1a
> 09: 00
> 0a: 00
> 0b: 00
> 0c: a0

RX_SAFE_MODE is 1 here, good.

> 0d: 00
> 0e: 08
> 10: 44
> 11: 00
> 12: ff
> 15: 00
> 17: 02
> 18: 00
> 1a: 57
> 1b: 2a
> 1c: 0b
> 1d: 01
> 1e: 1f
> 1f: 00
> 20: ff
> 21: ff
> 22: ff
> 23: ff
> 24: 00
> 25: 00
> 26: 00
> 27: 00
> 28: 00
> 29: 00
> 2a: 00
> 2b: 00
> 2c: 38
> 2d: 74
> 2e: 57
> 2f: 53
> 
> uname -a prints :
> Linux beaglebone 4.4.54-ti-r93
> 
> i've set the irq trigger to Mode 1 rising edge :
> interrupts = <14 1>;
> 
> and increased the Clock frequency to 7 MHZ but the result is the same.
> 
> Unfortunately i'm not able sniff reliable 7Mhz.
> 

7 is to high, try 4.

- Alex

[0] http://www.spinics.net/lists/linux-wpan/msg01597.html

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Sat, Jul 08, 2017 at 08:06:48PM +0200, Alexander Aring wrote:
...
> 
> > The Registers a configured as:
> > 
> > cat /sys/kernel/debug/regmap/spi1.0/registers
> > 
> > 01: 16
> > 02: 16
> > 03: 00
> > 04: 20
> > 05: 00
> > 06: 20
> > 07: ff
> > 08: 1a
> > 09: 00
> > 0a: 00
> > 0b: 00
> > 0c: a0
> 
> RX_SAFE_MODE is 1 here, good.
> 

It could be that I misunderstood the datasheet, and the RX_SAFE_MODE is
"released" on loosing CS. Which means we need to reenable the bit after
each received frame.

maybe you could check that? :-/

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Sat, Jul 08, 2017 at 08:11:13PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Sat, Jul 08, 2017 at 08:06:48PM +0200, Alexander Aring wrote:
> ...
> > 
> > > The Registers a configured as:
> > > 
> > > cat /sys/kernel/debug/regmap/spi1.0/registers
> > > 
> > > 01: 16
> > > 02: 16
> > > 03: 00
> > > 04: 20
> > > 05: 00
> > > 06: 20
> > > 07: ff
> > > 08: 1a
> > > 09: 00
> > > 0a: 00
> > > 0b: 00
> > > 0c: a0
> > 
> > RX_SAFE_MODE is 1 here, good.
> > 
> 
> It could be that I misunderstood the datasheet, and the RX_SAFE_MODE is
> "released" on loosing CS. Which means we need to reenable the bit after
> each received frame.
> 
> maybe you could check that? :-/
> 

one small note here, for that you need to make the register for
RX_SAFE_MODE volatile - don't trust regmap for now, because it's using
shadow register - with volatile it will not use shadow registering!

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Hi,
I do not use the SPIDEV fragment, so I've deleted it out of the Overlay.
The data sheet of the ATREB233 says that the SPI cut get up to 7.5 MHZ 
but decreasing it does have no positive effects.
My SPI Configuration is specified for the BBB.

I do think that released the RX_Save_MODE means, that the frame buffer 
is not any more protected, so that the hardware can override the 
FrameBuffer.
I've checked the value of register 0x0c periodically but it does not 
change its value while operating.  But i have no idea how to make the 
regmap volatile.

Best Regards
Sebastian Balz


Am 08.07.2017 um 20:14 schrieb Alexander Aring:
> Hi,
>
> On Sat, Jul 08, 2017 at 08:11:13PM +0200, Alexander Aring wrote:
>> Hi,
>>
>> On Sat, Jul 08, 2017 at 08:06:48PM +0200, Alexander Aring wrote:
>> ...
>>>> The Registers a configured as:
>>>>
>>>> cat /sys/kernel/debug/regmap/spi1.0/registers
>>>>
>>>> 01: 16
>>>> 02: 16
>>>> 03: 00
>>>> 04: 20
>>>> 05: 00
>>>> 06: 20
>>>> 07: ff
>>>> 08: 1a
>>>> 09: 00
>>>> 0a: 00
>>>> 0b: 00
>>>> 0c: a0
>>> RX_SAFE_MODE is 1 here, good.
>>>
>> It could be that I misunderstood the datasheet, and the RX_SAFE_MODE is
>> "released" on loosing CS. Which means we need to reenable the bit after
>> each received frame.
>>
>> maybe you could check that? :-/
>>
> one small note here, for that you need to make the register for
> RX_SAFE_MODE volatile - don't trust regmap for now, because it's using
> shadow register - with volatile it will not use shadow registering!
>
> - Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Sun, Jul 09, 2017 at 06:22:29PM +0200, Balz wrote:
> Hi,
> I do not use the SPIDEV fragment, so I've deleted it out of the Overlay.
> The data sheet of the ATREB233 says that the SPI cut get up to 7.5 MHZ but
> decreasing it does have no positive effects.
> My SPI Configuration is specified for the BBB.
> 

mh, ok. 7Mhz could be too high, I expierenced bad behaviours on RPI with
openlabs board which has no jumpwire etc. setup.

> I do think that released the RX_Save_MODE means, that the frame buffer is
> not any more protected, so that the hardware can override the FrameBuffer.
> I've checked the value of register 0x0c periodically but it does not change
> its value while operating.  But i have no idea how to make the regmap
> volatile.
>

You need to have it volatile otherwise the read will not trigger a register
read on the bus. Maybe there exists a runtime solution to add it via debugfs
to volatile registers. I know this way only, you can run the cat on
registers afterwards and it should trigger a register read. Acutally you
could check it on you logic analyzer (but there should be a lot of
register read, search for 0x0c).

Here is the diff, very easy (recompile kernel and boot it, sure... or
just at86rf230.ko replacement):

diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 548d9d026a85..858b07a4febc 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -311,6 +311,7 @@ at86rf230_reg_volatile(struct device *dev, unsigned int reg)
        case RG_VREG_CTRL:
        case RG_PLL_CF:
        case RG_PLL_DCU:
+       case RG_TRX_CTRL_2:
                return true;
        default:
                return false;

----------

I reread the datasheet and I think this will not happen, that we lost
RX_SAFE_MODE... because the datasheet [0] shows how to setup enable
"receive mode" inclusive address filtering etc. there is the
RX_SAFE_MODE setting mentioned. That says to me: we need it for hardware
init once OR when going into some RX state of at86rf233... but what an
ugly behaviour that it will drop RX_SAFE_MODE when changing state -
another question: would we always set the address filtering again then?
I don't know...

I maybe can ask "again" Atmel support for help me, but this support
interface of them are very ugly and I only got reponse the last time,
because somebody on the list had some support contract with them (I
think).

Also [0] for running in promiscuous mode (page 59) doesn't mention
anything about RX_SAFE_MODE! So question would be if RX_SAFE_MODE
working in promiscuous mode? Or does the hardware doesn't support it...
in this configuration.

The datasheet doesn't contain the information which I need to know... I
need the firmware of this chip >:-(

- Alex

[0] http://www.atmel.com/images/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf (PDF PAGE 56)

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

hi,

I figured out that you can disable the shadow registers (in the regmap 
dir) by writing "y" to "cache_bypass" by the command "echo y > 
cache_bypass", ore by setting the third char to y (in the corresponding 
line ) in the file access but this you cannot do in user space.

I've checked it out that if you write a "y" to "cache_bypass" that the 
drive reads all defined registers (seen in "range") from the device.
The value of ref 0x0C stays unchanged.

I would be very grateful if you could use you connections to Atmel.
Of cause you can refer to my proved logic-dump and pcap file in my dropbox

regards

Sebastian Balz

Am 09.07.2017 um 20:27 schrieb Alexander Aring:

> Hi,
>
> On Sun, Jul 09, 2017 at 06:22:29PM +0200, Balz wrote:
>> Hi,
>> I do not use the SPIDEV fragment, so I've deleted it out of the Overlay.
>> The data sheet of the ATREB233 says that the SPI cut get up to 7.5 MHZ but
>> decreasing it does have no positive effects.
>> My SPI Configuration is specified for the BBB.
>>
> mh, ok. 7Mhz could be too high, I expierenced bad behaviours on RPI with
> openlabs board which has no jumpwire etc. setup.
>
>> I do think that released the RX_Save_MODE means, that the frame buffer is
>> not any more protected, so that the hardware can override the FrameBuffer.
>> I've checked the value of register 0x0c periodically but it does not change
>> its value while operating.  But i have no idea how to make the regmap
>> volatile.
>>
> You need to have it volatile otherwise the read will not trigger a register
> read on the bus. Maybe there exists a runtime solution to add it via debugfs
> to volatile registers. I know this way only, you can run the cat on
> registers afterwards and it should trigger a register read. Acutally you
> could check it on you logic analyzer (but there should be a lot of
> register read, search for 0x0c).
>
> Here is the diff, very easy (recompile kernel and boot it, sure... or
> just at86rf230.ko replacement):
>
> diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
> index 548d9d026a85..858b07a4febc 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -311,6 +311,7 @@ at86rf230_reg_volatile(struct device *dev, unsigned int reg)
>          case RG_VREG_CTRL:
>          case RG_PLL_CF:
>          case RG_PLL_DCU:
> +       case RG_TRX_CTRL_2:
>                  return true;
>          default:
>                  return false;
>
> ----------
>
> I reread the datasheet and I think this will not happen, that we lost
> RX_SAFE_MODE... because the datasheet [0] shows how to setup enable
> "receive mode" inclusive address filtering etc. there is the
> RX_SAFE_MODE setting mentioned. That says to me: we need it for hardware
> init once OR when going into some RX state of at86rf233... but what an
> ugly behaviour that it will drop RX_SAFE_MODE when changing state -
> another question: would we always set the address filtering again then?
> I don't know...
>
> I maybe can ask "again" Atmel support for help me, but this support
> interface of them are very ugly and I only got reponse the last time,
> because somebody on the list had some support contract with them (I
> think).
>
> Also [0] for running in promiscuous mode (page 59) doesn't mention
> anything about RX_SAFE_MODE! So question would be if RX_SAFE_MODE
> working in promiscuous mode? Or does the hardware doesn't support it...
> in this configuration.
>
> The datasheet doesn't contain the information which I need to know... I
> need the firmware of this chip >:-(
>
> - Alex
>
> [0] http://www.atmel.com/images/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf (PDF PAGE 56)

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Mon, Jul 10, 2017 at 10:39:34AM +0200, Balz wrote:
> hi,
> 
> I figured out that you can disable the shadow registers (in the regmap dir)
> by writing "y" to "cache_bypass" by the command "echo y > cache_bypass", ore
> by setting the third char to y (in the corresponding line ) in the file
> access but this you cannot do in user space.
> 
> I've checked it out that if you write a "y" to "cache_bypass" that the drive
> reads all defined registers (seen in "range") from the device.
> The value of ref 0x0C stays unchanged.
> 
> I would be very grateful if you could use you connections to Atmel.
> Of cause you can refer to my proved logic-dump and pcap file in my dropbox
> 

tried it, gave up... seems to be everything has changed because
microchip & atmel stuff. You could try it...

You didn't answered my other question:

Do you transmit over monitor interface?

Also I don't have such issues with RPi, do you have some RPi around and
use _mainline_ Linux kernel. Very important _mainline_.

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Hi,

thank you as far.

i do have next Thursday the possibility to get a rpi.
I'am sorry.
yes i'am using it as monitor.
the configuration is :
     sudo iwpan "$wpan" del
     sudo iwpan "$phy" interface add "$wpan" type monitor
     sudo iwpan "$phy" set channel 0 "$channel"
     sudo ifconfig "$wpan" up

with $wpan == wpan0, $phy == phy0 and $channel = 26

So i try to get in touch with Atmel/Micochip and report the result.

Best Regards

Sebastian Balz

Am 10.07.2017 um 11:40 schrieb Alexander Aring:
 > Hi,
 >
 > On Mon, Jul 10, 2017 at 10:39:34AM +0200, Balz wrote:
 >> hi,
 >>
 >> I figured out that you can disable the shadow registers (in the 
regmap dir)
 >> by writing "y" to "cache_bypass" by the command "echo y > 
cache_bypass", ore
 >> by setting the third char to y (in the corresponding line ) in the file
 >> access but this you cannot do in user space.
 >>
 >> I've checked it out that if you write a "y" to "cache_bypass" that 
the drive
 >> reads all defined registers (seen in "range") from the device.
 >> The value of ref 0x0C stays unchanged.
 >>
 >> I would be very grateful if you could use you connections to Atmel.
 >> Of cause you can refer to my proved logic-dump and pcap file in my 
dropbox
 >>
 > tried it, gave up... seems to be everything has changed because
 > microchip & atmel stuff. You could try it...
 >
 > You didn't answered my other question:
 >
 > Do you transmit over monitor interface?
 >
 > Also I don't have such issues with RPi, do you have some RPi around and
 > use _mainline_ Linux kernel. Very important _mainline_.
 >
 > - Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Mon, Jul 10, 2017 at 01:50:30PM +0200, Balz wrote:
> Hi,
> 
> thank you as far.
> 
> i do have next Thursday the possibility to get a rpi.
> 
> I'am sorry.
> yes i'am using it as monitor.
> the configuration is :
>     sudo iwpan "$wpan" del
>     sudo iwpan "$phy" interface add "$wpan" type monitor
>     sudo iwpan "$phy" set channel 0 "$channel"
>     sudo ifconfig "$wpan" up
> 
> with $wpan == wpan0, $phy == phy0 and $channel = 26
>

ok. But do you transmit over monitor interface or not? It could be that
the transceiver overwrites framebuffer with tx frames. (only after some
xxx times when going to TX_ON isn't possible, it will do some force
change).

> So i try to get in touch with Atmel/Micochip and report the result.
> 

ok.

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Hi Alex,

The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a 
SRAM read(addr 0x00-0x7F)
I locked through the Code but could not find the Frame-Buffer reading part.

I would like to recompile the corresponding part and check if that 
changes something

Best Regards

Sebastian Balz


Am 10.07.2017 um 14:03 schrieb Alexander Aring:
> Hi,
>
> On Mon, Jul 10, 2017 at 01:50:30PM +0200, Balz wrote:
>
>> So i try to get in touch with Atmel/Micochip and report the result.
>>
> ok.
>
> - Alex
>

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote:
>
> Hi Alex,
>
> The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F)
> I locked through the Code but could not find the Frame-Buffer reading part.
>

We start the read frame buffer command at [0].

> I would like to recompile the corresponding part and check if that changes something
>

For me it sounds weird. You definitely lost the frame buffer
protection with that.
Is there some errata released where it stands you should use SRAM access?

If I would be atmel, then maybe try to use manual locks, see register
bits "RX_PDT_DIS". If they don't trust that automatic way doesn't
work.
You can change the code as well to use the manual way.

- Alex

[0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Hi Alex,

I've changed the Kernel module so that i read the Framebuffer as SRAM 
and not as FrameBuffer.
I've write a 0x00n followed by 0x00 to determine a SRAM read from the 
addr 0.

But the Kernel Module can not identity the frame length any more.

The Sniffed packages (all Packages have 143 byte length) do not show the 
behaviour any more.

Maybe the SRAM read access is protected and the Frame-buffer Read not...?

Best Regards

Sebastian Balz



Am 31.07.2017 um 15:48 schrieb Alexander Aring:
> Hi,
>
> On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote:
>> Hi Alex,
>>
>> The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F)
>> I locked through the Code but could not find the Frame-Buffer reading part.
>>
> We start the read frame buffer command at [0].
>
>> I would like to recompile the corresponding part and check if that changes something
>>
> For me it sounds weird. You definitely lost the frame buffer
> protection with that.
> Is there some errata released where it stands you should use SRAM access?
>
> If I would be atmel, then maybe try to use manual locks, see register
> bits "RX_PDT_DIS". If they don't trust that automatic way doesn't
> work.
> You can change the code as well to use the manual way.
>
> - Alex
>
> [0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote:
> Hi Alex,
>
> I've changed the Kernel module so that i read the Framebuffer as SRAM and
> not as FrameBuffer.
> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
> 0.
>
> But the Kernel Module can not identity the frame length any more.
>
> The Sniffed packages (all Packages have 143 byte length) do not show the
> behaviour any more.
>
> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>

I think frame buffer read access only.

"Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
 during a Frame Buffer read access, or on the radio transceiver’s
state change from
 RX_ON or RX_AACK_ON to another state.", see [0].

unless there is no errata which said is broken for frame buffer I am
not willing to change it to e.g. SRAM which would work.
As the datasheet says "Frame Buffer read access" only and not SRAM, foo.

- Alex

[0] http://www.atmel.com/images/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

2017-08-02 14:59 GMT-04:00 Alexander Aring <aring@mojatatu.com>:
> Hi,
>
> On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote:
>> Hi Alex,
>>
>> I've changed the Kernel module so that i read the Framebuffer as SRAM and
>> not as FrameBuffer.
>> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
>> 0.
>>
>> But the Kernel Module can not identity the frame length any more.
>>
>> The Sniffed packages (all Packages have 143 byte length) do not show the
>> behaviour any more.
>>
>> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>>
>
> I think frame buffer read access only.
>
> "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
>  during a Frame Buffer read access, or on the radio transceiver’s
> state change from
>  RX_ON or RX_AACK_ON to another state.", see [0].

Please try this patch:

diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index 548d9d026a85..a54f0a0d3fef 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -709,6 +709,8 @@ at86rf230_rx_read_frame_complete(void *context)
        struct sk_buff *skb;
        u8 len, lqi;

+       ieee802154_start_queue(lp->hw);
+
        len = buf[1];
        if (!ieee802154_is_valid_psdu_len(len)) {
                dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
@@ -824,6 +826,9 @@ static irqreturn_t at86rf230_isr(int irq, void *data)

        disable_irq_nosync(irq);

+       if (!lp->is_tx)
+               ieee802154_stop_queue(lp->hw);
+
        ctx = kzalloc(sizeof(*ctx), GFP_ATOMIC);
        if (!ctx) {
                enable_irq(irq);

I think I know what could be going on...

It's "... to another state."... Maybe when a RX irq occurs during the
spi async handling there could be some "xmit" callbacks... This will
change the transceiver into another state... (not directly, but so far
I know it queues for state change). So when it will automatically go
into RX_AACK_ON then it will change the state to something else and
allows framebuffer overwrite.

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

switched back to my new mail addres... sorry.

On Wed, Aug 2, 2017 at 5:55 PM, Alexander Aring <alex.aring@gmail.com> wrote:
> Hi,
>
> 2017-08-02 14:59 GMT-04:00 Alexander Aring <aring@mojatatu.com>:
>> Hi,
>>
>> On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote:
>>> Hi Alex,
>>>
>>> I've changed the Kernel module so that i read the Framebuffer as SRAM and
>>> not as FrameBuffer.
>>> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
>>> 0.
>>>
>>> But the Kernel Module can not identity the frame length any more.
>>>
>>> The Sniffed packages (all Packages have 143 byte length) do not show the
>>> behaviour any more.
>>>
>>> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>>>
>>
>> I think frame buffer read access only.
>>
>> "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
>>  during a Frame Buffer read access, or on the radio transceiver’s
>> state change from
>>  RX_ON or RX_AACK_ON to another state.", see [0].
>
> Please try this patch:
>
> diff --git a/drivers/net/ieee802154/at86rf230.c
> b/drivers/net/ieee802154/at86rf230.c
> index 548d9d026a85..a54f0a0d3fef 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -709,6 +709,8 @@ at86rf230_rx_read_frame_complete(void *context)
>         struct sk_buff *skb;
>         u8 len, lqi;
>
> +       ieee802154_start_queue(lp->hw);
> +
>         len = buf[1];
>         if (!ieee802154_is_valid_psdu_len(len)) {
>                 dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
> @@ -824,6 +826,9 @@ static irqreturn_t at86rf230_isr(int irq, void *data)
>
>         disable_irq_nosync(irq);
>
> +       if (!lp->is_tx)
> +               ieee802154_stop_queue(lp->hw);
> +
>         ctx = kzalloc(sizeof(*ctx), GFP_ATOMIC);
>         if (!ctx) {
>                 enable_irq(irq);
>
> I think I know what could be going on...
>
> It's "... to another state."... Maybe when a RX irq occurs during the
> spi async handling there could be some "xmit" callbacks... This will
> change the transceiver into another state... (not directly, but so far
> I know it queues for state change). So when it will automatically go
> into RX_AACK_ON then it will change the state to something else and
> allows framebuffer overwrite.

it could be that there exists a race when stop queue is running and
currently a xmit is going on...
I currently have no idea how to solve it and need to have more details
what happens when the transceiver is in BUSY_RX and we do another
state change? Will it be queued or not (so after BUSY_RX it will
change to RX_ON and then another state)?

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Wed, Aug 2, 2017 at 6:16 PM, Alexander Aring <aring@mojatatu.com> wrote:
> Hi,
>
...
>>
>> It's "... to another state."... Maybe when a RX irq occurs during the
>> spi async handling there could be some "xmit" callbacks... This will
>> change the transceiver into another state... (not directly, but so far
>> I know it queues for state change). So when it will automatically go
>> into RX_AACK_ON then it will change the state to something else and
>> allows framebuffer overwrite.
>
> it could be that there exists a race when stop queue is running and
> currently a xmit is going on...
> I currently have no idea how to solve it and need to have more details
> what happens when the transceiver is in BUSY_RX and we do another
> state change? Will it be queued or not (so after BUSY_RX it will
> change to RX_ON and then another state)?
>

Sorry, I remember... you told you don't send anything? Then this can't
be the issue. :-(
... but maybe we should stop transmit queue while receiving.

- Alex

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Balz]

Hi,

as mention the packages seems to be valid expected the package size of 143.
I tried to manipulate the kernel module so that is read the SRAM but 
I've trouble with reading the correct frame length. For me that is to 
deep into kernel programming (I have no knowledge with the Linux kernel).

Temporally we switch to a RIOT based SLIP sniffer.

Thank you very much fro your help.

Best Regards
Sebastian Balz


Am 31.07.2017 um 15:48 schrieb Alexander Aring:
> Hi,
>
> On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote:
>> Hi Alex,
>>
>> The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F)
>> I locked through the Code but could not find the Frame-Buffer reading part.
>>
> We start the read frame buffer command at [0].
>
>> I would like to recompile the corresponding part and check if that changes something
>>
> For me it sounds weird. You definitely lost the frame buffer
> protection with that.
> Is there some errata released where it stands you should use SRAM access?
>
> If I would be atmel, then maybe try to use manual locks, see register
> bits "RX_PDT_DIS". If they don't trust that automatic way doesn't
> work.
> You can change the code as well to use the manual way.
>
> - Alex
>
> [0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758

Re: Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

[Alexander Aring]

Hi,

On Thu, Aug 10, 2017 at 7:59 AM, Balz <Sebastian.balz@freenet.de> wrote:
> Hi,
>
> as mention the packages seems to be valid expected the package size of 143.
> I tried to manipulate the kernel module so that is read the SRAM but I've
> trouble with reading the correct frame length. For me that is to deep into
> kernel programming (I have no knowledge with the Linux kernel).
>

so you mention that you got a frame length which is not valid. It
can't be large than 127.
This is an on the air field (PHR), so it could be that somebody while
transmitting is wrong.
_IMPORTANT_ this (PHR) field is not part of CRC (FCS).
Also we filter on such frame length and read the whole framebuffer
then and trim it to 127 bytes (for monitoring could be interesting)...

I would check with an e.g. ATUSB if you receive the same frames... I
would only trust other sniffer devices if you know how they filter or
simple drop such frames or do whatever their policy is.

btw:

I bet many other drivers doesn't check on valid PHR field and so far
they run into bufferoverflows...

- Alex