Hi, On Wed, Aug 31, 2022 at 11:39 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > 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 What is a crafted ACK here? > 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 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? > depending on what mac802154 is doing, for scan it's required to switch the filter level to promiscuous? > For now there is only the promiscuous mode being applied and the user > has no knowledge about it, it's just something internal. > Okay, sounds good. > 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. > no, it does not. Okay, you can hide the promiscuous mode driver callback from start()... but yes the goal would be to remove the promiscuous mode op in future. > > 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? > I am not sure what exactly here is "dedicated "filtering" PHY flag" if it's the hwflags it was never made to be changed during runtime. I also don't know what "yet another rework of the API" means here, there is a current behaviour which we can assume and only hwsim is a little bit out of range which should overwrite the "default". > > 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. > okay. - Alex
