From: Michal Kazior <michal@xxxxxxxxx>
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")
Turns out chirping was omitted. As such chirping
wasn't working on drivers with restrictive rx
filters.
I've found this while trying to get ath9k working
as a chirping STA Enrollee.
The problem wasn't seen on, eg. mac80211 hwsim
driver.
Signed-off-by: Michal Kazior <michal@xxxxxxxxx>
---
wpa_supplicant/dpp_supplicant.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
index 09355cf7f..0eef64ca3 100644
--- 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);
if (eloop_register_timeout(2, 0, wpas_dpp_chirp_timeout,
wpa_s, NULL) < 0)
wpas_dpp_chirp_stop(wpa_s);
--
2.27.0
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
