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

[Michael Hennerich <michael.hennerich@analog.com>]

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.
So if there are non compliant IEEE802154 nodes around we can turn it off.

Either way is fine with me.


>
> - Alex
>
> [0] http://wpan.cakelab.org/releases/
>


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif