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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
