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

[Michal Kazior]

On Tue, Feb 9, 2021 at 7:40 PM Jouni Malinen <j at w1.fi> 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 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.

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ł