Hi, On Sat, Sep 3, 2022 at 10:20 AM Alexander Aring <aahringo@xxxxxxxxxx> wrote: > > Hi, > > On Fri, Sep 2, 2022 at 8:08 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > ... > > > > > > I am sorry, I never looked into Zephyr for reasons... Do they not have > > > something like /proc/interrupts look if you see a counter for your > > > 802.15.4 transceiver? > > > > > > > Also, can you please clarify when are we talking about software and > > > > when about hardware filters. > > > > > > > > > > Hardware filter is currently e.g. promiscuous mode on or off setting. > > > Software filtering is depending which receive path the frame is going > > > and which hardware filter is present which then acts like actually > > > with hardware filtering. > > > I am not sure if this answers this question? > > > > I think my understand gets clearer now that I've digged into Zephyr's > > ieee802154 layer and in the at86rf230 datasheet. > > > > okay, I think for zephyr questions you are here on the wrong mailinglist. > > > I will answer the previous e-mail but just for not I wanted to add that > > I managed to get Zephyr working, I had to mess around in the code a > > little bit and actually I discovered a net command which is necessary > > to use in order to turn the iface up, whatever. > > > > aha. > > > So I was playing with the atusb devices and I _think_ I've found a > > firmware bug or a hardware bug which is going to be problematic. In > > the firmware is open source, I think it's fine to send patches here (I > did it as well once for do a quick hack to port it to rzusb) the atusb > is "mostly" at the point that they can do open hardware from the > qi-hardware organization. > > > iface.c, when creating the interface, if you set the hardware filters > > (set_panid/short/ext_addr()) there is no way you will be able to get a > > fully transparent promiscuous mode. I am not saying that the whole > > What is a transparent promiscuous mode? > > > promiscuous mode does not work anymore, I don't really know. What I was > > interested in were the acks, and getting them is a real pain. At least, > > enabling the promiscuous mode after setting the hw filters will lead to > > the acks being dropped immediately while if the promiscuous mode is > > enabled first (like on monitor interfaces) the acks are correctly > > forwarded by the PHY. > > If we would not disable AACK handling (means we receive a frame with > ack requested bit set we send a ack back) we would ack every frame it > receives (speaking on at86rf233). > > > > > While looking at the history of the drivers, I realized that the > > TX_ARET mode was not supported by the firmware in 2015 (that's what you > > There exists ARET and AACK, both are mac mechanisms which must be > offloaded on the hardware. Note that those only do "something" if the > ack request bit in the frame is set. > > ARET will retransmit if no ack is received after some while, etc. > mostly coupled with CSMA/CA handling. We cannot guarantee such timings > on the Linux layer. btw: mac80211 can also not handle acks on the > software layer, it must be offloaded. > > AACK will send a back if a frame with ack request bit was received. will send an ack back* - Alex
