Hi, On Wed, Aug 31, 2022 at 8:09 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hello again, > > miquel.raynal@xxxxxxxxxxx wrote on Wed, 31 Aug 2022 17:39:03 +0200: > > > Hi Alexander & Stefan, > > > > aahringo@xxxxxxxxxx wrote on Mon, 29 Aug 2022 22:23:09 -0400: > > > > I am currently testing my code with the ATUSB devices, the association > > works, so it's a good news! However I am struggling to get the > > association working for a simple reason: the crafted ACKs are > > transmitted (the ATUSB in monitor mode sees it) but I get absolutely > > nothing on the receiver side. > > > > The logic is: > > > > coord0 coord1 > > association req -> > > <- ack > > <- association response > > ack -> > > > > The first ack is sent by coord1 but coord0 never sees anything. In > > practice coord0 has sent an association request and received a single > > one-byte packet in return which I guess is the firmware saying "okay, Tx > > has been performed". Shall I interpret this byte differently? Does it > > mean that the ack has also been received? > > I think I now have a clearer understanding on how the devices behave. > > I turned the devices into promiscuous mode and could observe that some > frames were considered wrong. Indeed, it looks like the PHYs add the > FCS themselves, while the spec says that the FCS should be provided to > the PHY. Anyway, I dropped the FCS calculations from the different MLME > frames forged and it helped a lot. > This is currently the case because monitor interfaces and AF_PACKET will not have the FCS in the payload. As you already figured out you can't refer 802.15.4 promiscuous mode to mac802154 promiscuous mode, it was a historically growing term as people wanted to have a sniffer device and used a promiscuous term from a datasheet (my guess). Vendors has a different meaning of promiscuous mode as the one from 802.15.4. IFF_PROMISC should be mapped to non-filtered mode which is more equal to a sniffer device. However we need to find solutions which fulfill everybody. > I also kind of "discovered" the concept of hardware address filtering > on atusb which makes me realize that maybe we were not talking about > the same "filtering" until now. > > Associations and disassociations now work properly, I'm glad I fixed > "everything". I still need to figure out if using the promiscuous mode > everywhere is really useful or not (maybe the hardware filters were > disabled in this mode and it made it work). However, using the > promiscuous mode was the only way I had to receive acknowledgements, > otherwise they were filtered out by the hardware (the monitor was > showing that the ack frames were actually being sent). > This is correct, the most hardware will turn off automatic ackknowledge handling if address filtering is off (I am sure I said that before). We cannot handle acks on mac802154 if they are time critical. > Finally, changing the channel was also a piece of the puzzle, because I > think some of my smart light bulbs tried to say hello and it kind of > disturbed me :) > > > I could not find a documentation of the firmware interface, I went > > through the wiki but I did not find something clear about what to > > expect or "what the driver should do". But perhaps this will ring a > > bell on your side? > > > > [...] > > > > > I did not see the v2 until now. Sorry for that. > > > > Ah! Ok, no problem :) > > > > > > > > However I think there are missing bits here at the receive handling > > > side. Which are: > > > > > > 1. Do a stop_tx(), stop_rx(), start_rx(filtering_level) to go into > > > other filtering modes while ifup. > > > > Who is supposed to change the filtering level? > > > > For now there is only the promiscuous mode being applied and the user > > has no knowledge about it, it's just something internal. > > > > Changing how the promiscuous mode is applied (using a filtering level > > instead of a "promiscuous on" boolean) would impact all the drivers > > and for now we don't really need it. > > > > > I don't want to see all filtering modes here, just what we currently > > > support with NONE (then with FCS check on software if necessary), > > > ?THIRD/FOURTH? LEVEL filtering and that's it. What I don't want to see > > > is runtime changes of phy flags. To tell the receive path what to > > > filter and what's not. > > > > Runtime changes on a dedicated "filtering" PHY flag is what I've used > > and it works okay for this situation, why don't you want that? It > > avoids the need for (yet) another rework of the API with the drivers, > > no? > > > > > 2. set the pan coordinator bit for hw address filter. And there is a > > > TODO about setting pkt_type in mac802154 receive path which we should > > > take a look into. This bit should be addressed for coordinator support > > > even if there is the question about coordinator vs pan coordinator, > > > then the kernel needs a bit as coordinator iface type parameter to > > > know if it's a pan coordinator and not coordinator. > > > > This is not really something that we can "set". Either the device > > had performed an association and it is a child device: it is not the > > PAN coordinator, or it initiated the PAN and it is the PAN coordinator. > > There are commands to change that later on but those are not supported. > > > > The "PAN coordinator" information is being added in the association > > series (which comes after the scan). I have handled the pkt_type you are > > mentioning. > > > > > I think it makes total sense to split this work in transmit handling, > > > where we had no support at all to send something besides the usual > > > data path, and receive handling, where we have no way to change the > > > filtering level besides interface type and ifup time of an interface. > > > We are currently trying to make a receive path working in a way that > > > "the other ideas flying around which are good" can be introduced in > > > future. > > > If this is done, then take care about how to add the rest of it. > > > > > > I will look into v2 the next few days. > > If possible, I would really like to understand what you expect in terms > of filtering. Maybe as well a short snippet of code showing what kind > of interface you have in mind. Are we talking about a rework of the > promiscuous callback? Are we talking about the hardware filters? What I try to do that over the weekend. Monday is a holiday here. > are the inputs and outputs for these callbacks? What do we expect from > the drivers in terms of advertising? I will be glad to make the > relevant changes once I understand what is needed because on this topic > I have a clear lack of experience, so I will try to judge what is > reachable based on your inputs. ok. Thanks. - Alex
