On Sat, Mar 21, 2020 at 03:04:27PM +0100, Janusz Dziedzic wrote: > Just check dpp_pkex* test cases in my remote test environment (ath9k > devices) and seems by default fail: > - supplicant using remain_on_channel here > - we don't receive broadcast action frame(s) (PKEX exchange request) > - I suspect HW rx filter configuration don't work correctly here Yes, that's correct and thanks for the reminder. I had this in my queue somewhere, but never got as far as figuring out what exactly should be done to resolve this. > In case will add monitor interface to the iface that ath9k station > using, test case always pass (we receive this action frame(s) when > remain-on-channel). It does not actually need to be a monitor interface, i.e., any additional vif that is up should be sufficient.. The key point here is in getting ath9k to include ATH9K_RX_FILTER_MCAST_BCAST_ALL in the RX filter configuration. That happens if nvifs > 1 or FIF_OTHER_BSS is included (the former is based on multiple vifs and the latter is based on mesh being used). > Seems we pass this for hwsim, but I suspect we don't use hwsim filters? mac80211_hwsim does not filter out frames in the same manner as most hardware designs do on the RX path. > I see that wpa_supplicant register different action frames and finally > we configure this in mgmt_frame_register() next > ieee80211_mgmt_frame_register(). > Do we miss some functionality here (in mac80211) or this is pure ath9k bug? It's more of an undefined behavior.. DPP happens to be the first (and currently only) used of broadcast Public Action frames and it looks like number of WLAN designs filter such frames at one (or even multiple) points in the stack since there was no need to waste power in processing them. We don't currently have any means for user space to indicate that it would be nice to be able to receive broadcast Public Action frames (i.e., Management frames that are sent outside the context of an association with A1=A3=ff:ff:ff:ff:ff:ff). Since delivery of such frames to upper layers may require some designs to enable promiscuous RX behavior, this can result in undesired use of power in some devices and as such, it would be nice to be able to do this only when there is a known user for such frames (e.g., DPP listen mode enabled). That ath9k case of ATH9K_RX_FILTER_MCAST_BCAST_ALL may not be that expensive, but other drivers might need to enable full promiscuous receive and drop significantly larger number of undesired frames in mac80211 to have a noticeable impact. If we were to add that user space registration for broadcast Public Action frames, we could then handle that in mac80211 by adding a new enum ieee80211_filter_flags value (e.g., FIF_BROADCAST_PUBLIC_ACTION) and have ath9k map that to ATH9K_RX_FILTER_MCAST_BCAST_ALL. wpa_supplicant would then use this new registration mechanism based on when it expects to be able to receive DPP frames (i.e., when DPP_LISTEN is in progress). > Interesting, that 'monitor trick' doesn't work for intel-ax200. It should be noted that the frames can be dropped at other layers as well. There are WLAN firmware designs that drop these frames and make those cases work with DPP PKEX is likely going to require a firmware change.. Furthermore, the exact trick depends on the driver (that nvifs being larger then one in case of ath9k), so it is not surprising to see different behavior.. As another example, AR9170/carl9170 seems to work without any such tricks and same is the case for ath10k with firmware builds that enable this case explicitly for DPP. Anyway, it would be good to add this registration mechanism for broadcast Public Action frame RX to fix the known cases (at least ath9k and ath9k_htc) and to make this details about DPP more explicitly documented and known for others to find and address in driver or firmware design for RX filtering. -- Jouni Malinen PGP id EFC895FA
