[PATCH 2/2] wpa_supplicant: fix chirping on sta enrollee scenario

[Jouni Malinen]

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 at w1.fi> 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.

> > > 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.

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.

-- 
Jouni Malinen                                            PGP id EFC895FA