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/ -- 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
