On Tue, Feb 9, 2021 at 7:40 PM Jouni Malinen <j@xxxxx> wrote: > On Mon, Feb 08, 2021 at 03:20:37PM +0100, Michal Kazior wrote: > > On Sat, Feb 6, 2021 at 3:14 PM Jouni Malinen <j@xxxxx> wrote: > > > This sounds strange.. The response to chirping would be a unicast frame, > > > so that hardware/firmware RX filter change should not have any impact > > > here. > > > > Now that you say it, it would make sense to expect a unicast frame to > > be sent back to the chirping station. But that's not what is > > happening. > > > > This is output from a script I used to test the problem. It prefixes > > prints from wpa_s and hostapd, and you can see hostapd is responding > > with a type=0 bcast. > > That's a bug.. I'll fix it so that the Authentication Request frame goes > out as a unicast frame to the source address of the Presence > Announcement which is what the tech spec defines for this sequence. Thanks! > > > > diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c > > > > @@ -3420,6 +3420,7 @@ static void wpas_dpp_chirp_tx_status(struct wpa_supplicant *wpa_s, > > > > wpa_printf(MSG_DEBUG, "DPP: Chirp send completed - wait for response"); > > > > + wpas_dpp_listen_start(wpa_s, freq); > > > > > > This looks quite incorrect thing to do.. This function is called when > > > the TX operation with 2000 ms wait for response gets TX status. It would > > > not be appropriate to start DPP listen while that 2000 ms wait for the > > > response is ongoing. > > > > Do you mean that it's racy? I guess it is... The response may already > > be lost when tx-status for the chirp is processed. Or do you mean > > something else here? > > Starting listen mode (ROC in mac80211) while already in > offchannel-TX-with-wait-for-response (also ROC) does not sound good > since there are constraints on how mac80211 allows ROCs to be combined > or extended. Oh, you're right. > This would also be a race condition since this call happens from TX > status handler and the Authentication Request frame may have already > been transmitted, but this was not my main concern (but it sounds like a > valid concern). > > Since there are cases where the Authentication Request frame might still > be sent to the broadcast address while the Enrollee is in the chirping > loop, it would make sense to update the hardware RX filters. However, > this should be done without introducing a separate listen operation. > Wouldn't a call to wpa_drv_dpp_listen(wpa_s, true) when starting > chirping be all that's needed here? That would then need to be stopped > when chirping state terminates. I think this is what I tried originally, but apparently didn't go that route for some reason that I can't remember anymore. I'll see what I can do. Michał _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
