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

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

Hi,

On Tue, Dec 08, 2015 at 05:02:15PM +0100, Michael Hennerich wrote:
> On 12/08/2015 04:53 PM, Alexander Aring wrote:
> >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?
> 
> I thought that ACK handling is mandatory for 802.15.4.

It is, otherwise some MLME-ops would not functional. The _open_ _source_
reality outside looks different. There are of course nodes which doesn't
support ack handling (I have some contiki nodes with cc2520, but so far
I know contiki also handles dataframes with 6LoWPAN only).

I also didn't saw any OS implementation for MLME-ops :( I know the Xbee [0]
transceiver which is a "kind" of HardMAC transceiver. MLME-ops can be
triggered by right "AT-FOO" uart command.

I know that Christopher Friedt want to have some MLME features inside
the kernel and already worked on some parts for scanning.

> So if there are non compliant IEEE802154 nodes around we can turn it off.
> 
> Either way is fine with me.
> 

Okay. It's one simple switch to change it. I would wait here for Stefans
opinion about that.


- Alex

[0] https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf