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