On Sat, Feb 6, 2021 at 3:14 PM Jouni Malinen <j@xxxxx> wrote:
>
> On Tue, Dec 15, 2020 at 09:34:55AM +0000, Michal Kazior wrote:
> > Some time ago it was found some drivers are
> > setting their hw/ucode rx filters restrictively
> > enough to prevent DPP multicast frames from being
> > delivered.
> >
> > A set of patches was introduced to the kernel and
> > ath9k driver as well as hostapd, eg.
> >
> > a39e9af90 ("nl80211: DPP listen mode callback")
> > 4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")
>
> So all this applies to patch 1/2 where hostapd side was not previously
> covered. However, I'm not sure I understand why that description is here
> in patch 2/2 as well..
I felt it's similar enough it warrants the same context to be provided.
> > Turns out chirping was omitted. As such chirping
> > wasn't working on drivers with restrictive rx
> > filters.
>
> 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.
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=13
> hapd wlp2s0: DPP-CHIRP-RX id=1 src=2c:d0:5a:66:88:74 freq=2412 hash=c4919f3a9600ad74f07614e2efcb63879bc6dbebf57a55a31dfcea9514ecc9d5
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> wpas wlp11s0: DPP-RX src=9c:b7:0d:43:77:48 freq=2412 type=0
> wpas wlp11s0: DPP-CHIRP-STOPPED
> wpas wlp11s0: DPP-TX dst=9c:b7:0d:43:77:48 freq=2412 type=1
> hapd wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=1
> hapd wlp2s0: DPP-AUTH-DIRECTION mutual=0
> hapd wlp2s0: DPP-TX dst=2c:d0:5a:66:88:74 freq=2412 type=2
> hapd wlp2s0: DPP-TX-STATUS dst=2c:d0:5a:66:88:74 result=SUCCESS
> hapd wlp2s0: DPP-AUTH-SUCCESS init=1
> hapd wlp2s0: DPP-CONF-REQ-RX src=2c:d0:5a:66:88:74
> hapd wlp2s0: DPP-BAND-SUPPORT 81,83,84,115,116,117,118,119,120,121,122,123,124,125,126,127
> hapd wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=11
> hapd wlp2s0: DPP-CONF-SENT
(snip)
This is buffered a bit but it is roughly chronological.
Without this patch what I see is this:
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> hapd wlp2s0: DPP-RX src=2c:d0:5a:66:88:74 freq=2412 type=13
> hapd wlp2s0: DPP-CHIRP-RX id=1 src=2c:d0:5a:66:88:74 freq=2412 hash=5da8e3eaea337eca38b78a12787e83382b99628a16f675003757ed73720f1318
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd nl80211: kernel reports: Match already configured
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd nl80211: kernel reports: Match already configured
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd nl80211: kernel reports: Match already configured
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=13
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13
> wpas wlp11s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=13
> hapd wlp2s0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2412 type=0
> hapd nl80211: kernel reports: Match already configured
> hapd DPP: No response received from responder - stopping initiation attempt
> hapd wlp2s0: DPP-AUTH-INIT-FAILED
> > 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?
Michał
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
