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..
> 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.
> 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.
Could you please provide more details on what exactly this is trying to
do and what kind of a frame is not received without this addition?
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
