Hi, On Sat, Sep 3, 2022 at 12:06 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Alexander, > > aahringo@xxxxxxxxxx wrote on Sat, 3 Sep 2022 10:20:24 -0400: > > > 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? > > I observe something very weird: > > A/ If at start up time we set promisc_mode(true) and then we set the hw > address filters, all the frames are forwarded to the MAC. > > B/ If at start up time we set the hw address filters and then set > promisc_mode(true), there is some filtering happening (like the Acks > which are dropped by the PHY. > > I need to investigate this further because I don't get why in case B we > don't have the same behavior than in case A. > Looking in the datasheet I see only set address filters -> then setting promiscuous mode is specified? Not the other way around... > > > 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). > > Yes, but when sending MAC frames I would like to: > - be in promiscuous mode in Rx (tx paused) in order for the MAC to be > aware of the acks being received (unless there is another way to do > that, see below) > - still ack the received frames automatically > > Unless we decide that we must only ack the expected frames manually? > We can't handle ack frames on mac802154 in my opinion. Or what does manually mean? Is the ack frame required as a mac command operation or as a response to a transmitted frame because the other side will do retransmissions if they don't see an ack back? The second case is not possible to implement on mac802154, it must be offloaded. > > > 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. > > Absolutely (for the record, that's also an issue I had with Zephyr, I > had to use the shell to explicitly ask the AR bit to be set in the > outgoing frames, even though this in most MAC frames this is not a user > choice, it's expected by the spec). > fyi: we have also a default_ackreq behaviour if we set the ack frame on all data frames or not. However it's currently set to not set the ackreq bit because most hardware outside can't handle it (even if required by the spec). If you have a requirement to set ack request bit then do it, if there is hardware outside which cannot handle it, it's their problem. However the dataframes which are sent via user space socket depending on the use case if they want to set it or not but if they set it you need to know your network. > > 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. > > On the Tx side, when sending eg. an association request or an > association response, I must expect and wait for an ack. This is > what I am struggling to do. How can I know that a frame which I just > transmitted has been acked? Bonus points, how can I do that in such a > way that it will work with other devices? (hints below) > You can't do this in mac802154 if there is a timing critical requirement here. Is there a timing critical requirement here? > > AACK will send a back if a frame with ack request bit was received. > > > > > say in a commit) I have seen no further updates about it so I guess > > > it's still not available. I don't see any other way to know if a > > > frame's ack has been received or not reliably. > > > > You implemented it for the at86rf230 driver (the spi one which is what > > also atusb uses). You implemented the > > > > ctx->trac = IEEE802154_NO_ACK; > > > > which signals the upper layer that if the ack request bit is set, that > > there was no ack. > > > > But yea, there is a missing feature for atusb yet which requires > > firmware changes as well. > > :'( > > Let's say I don't have the time to update the firmware ;). I also assume > that other transceivers (or even the drivers) might be limited on this > regard as well. How should I handle those "I should wait for the ack to > be received" situation while trying to associate? > If other transceivers cannot handle giving us feedback if ack was received or not and we have the mandatory requirement to know it, it is poor hardware/driver. As I said if the spec requires to check on an ack or not we need to get his information, if the hardware/driver can't deliver this... then just assume an ACK was received as it returns TX_SUCCESS (or whatever the return value was). I said before that some hardware will act weird if they don't support it. > The tricky case is the device receiving the ASSOC_REQ: > - the request is received > - an ack must be sent (this is okay in most cases I guess) > - the device must send an association response (also ok) > - and wait for the response to be acked... > * either I use the promisc mode when sending the response > (because of possible race conditions) and I expect the ack to > be forwarded to the MAC > -> This does not work on atusb, enabling promiscuous > mode after the init does not turn the PHY into > promiscuous mode as expected (discussed above) > * or I don't turn the PHY in promiscuous mode and I expect it > to return a clear status about if the ACK was received > -> But this seem to be unsupported with the current > ATUSB firmware, I fear other devices could have similar > limitations > * or I just assume the acks are received blindly > -> Not sure this is robust enough? > Assume you always get an ack back until somebody implements this feature in their driver (It's already implemented so as they return TX_SUCCESS). We cannot do much more I think... it is not robust but then somebody needs to update the driver/firmware. It's more weird if the otherside does not support AACK, because ARET will send them 3 times (by default) the same frame. That's why we have the policy to not set the ackreq bit if it's not required. > What is your "less worse" choice? > > > Btw: I can imagine that hwsim "fakes" such > > offload behaviours. > > My current implementation actually did handle all the acks (waiting for > them and sending them) from the MAC. I'm currently migrating the ack > sending part to the hw. For the reception, that's the big question. > In my opinion we should never deal with ack frames on mac802154 level, neither on hwsim, this is an offloaded functionality. What I have in mind is to fake a "TX_NO_ACK" return value as a probability parameter to return it sometimes. E.g. as netem and drop rate, etc. Then we could do some testing with it. > > > Do you think I can just ignore the acks during an association in > > > mac802154? > > > > No, even we should WARN_ON ack frames in states we don't expect them > > because they must be offloaded on hardware. > > > > I am not sure if I am following what is wrong with the trac register > > and NO_ACK, this is the information if we got an ack or not. Do you > > need to turn off address filters while "an association"? > > If we have access to the TRAC register, I believe we no longer need to > turn off address filters. > That sounds good. - Alex
