Re: [PATCH] drivers/net/ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154

[Alexander Aring <alex.aring@gmail.com>]

Hi,

On Tue, Dec 08, 2015 at 09:07:43AM +0100, Michael Hennerich wrote:
> On 12/07/2015 03:12 PM, Alexander Aring wrote:
> >On Mon, Dec 07, 2015 at 02:34:29PM +0100, Michael Hennerich wrote:
> >...
> >>>Stefan, maybe you testing with the ATUSB firmware which going _not_
> >>>into RX_AACK_ON. This was one of my lastest changes according to the
> >>>ATUSB firmware. Please check that, otherwise the atusb doesn't send
> >>>ack frames if ackrequest bit is set after receiving.
> >>
> >>I was wondering where can I buy the ATUSB?
> >>On the pulster page I can't find it.
> >>
> >
> >They are all out of stock, everywhere. I cc Werner maybe he will bring
> >back the atusb again. He do his stuff all open source and a possible
> >solution would be a Kickstarter project.
> >
> >Another option would be:
> >
> >  - Produce your own atusb
> >  - I know that "Christopher Friedt" produced some, maybe he will give/sell
> >    some. :-) I cc'ed him here.
> >  - use the experimental firmware [1] on RZUSBStick [0] support. Basics
> >    functionality only and not stable such atusb. I ported the firmware
> >    to this stick, it can be used by atusb driver. The transceiver is a
> >    different -> at86rf230... and this transceiver we also doesn't
> >    support by the at86rf230 because it's too different and a huge
> >    errata.
> 
> Would be nice to have a USB MAC8021511.
> Guess I need to wait for the next lot being produced.
> 
> 

ok. The RZUSBSTICK is still available but very poor state.

> >
> >>In general why is the framework not requesting ACKs on all non broadcast
> >>DATA frames?
> >>
> >>There is an option if turned on - it'll also request ACks on broadcasts...
> >
> >I suppose you use the af802154 socket family. I didn't touched the code
> >and this socket family is full of bugs. We need a replacement for that.
> >
> >The socket code which I was working is AF_PACKET.
> >
> >In case of AF_PACKET:
> >
> >  dgram sockets: extended address and intra_pan communciaton only. The
> >                 AF_PACKET UAPI doesn't offer more address information.
> >		We do a mapping to this currently, other option would be
> >		to disable DGRAM on AF_PACKET. It's not possible to send
> >		broadcast frames with that.
> >		If you need that, something similar like af802154 should
> >		be available, but it's currently broken.
> >
> >  raw sockets:   You can build the mac frame inside userspace with
> >                 complete control fc and address settings. We don't check
> >		this frame if it's valid. This is not a bug.
> >
> >
> >and 6LoWPAN:
> >
> >6LoWPAN doesn't do that, the check should be at [2]. If it's currently
> >broken at your side?
> 
> Maybe - I still use the lowpan-tools.
> And it locks like ACKs must be enabled via NL802154_CMD_SET_ACKREQ_DEFAULT,
> which lowpan-tools doesn't do.
> Wondering why it's not by default enabled...
> So I patched my kernel, probably in the wrong place.
> 

The lowpan-tools are deprecated. The official website is back (from what
I recovered), you can get wpan-tools at [0].

The ackreq_default is false by default (which indicates no ARET
handling/no ackrequest bit is set) because this requires that the other
side can deal with ack handling. Otherwise the node will get the frame 3
times.

The conclusion is to set the ack handling default to false, if you know
your network can do ack handling then you can turn it on with the
wpan-tools.

Do you think we should enable it by default and if there are non IEEE
802.15.4 valid nodes around which doesn't support ACK handling we should
simple ignore that?

- Alex

[0] http://wpan.cakelab.org/releases/