hostapd: Fix dpp_listen in DPP responder scenario

Some time ago it was found some drivers are setting their hw/ucode RX
filters restrictively enough to prevent broadcast DPP Action frames from
being received at upper layers in the stack.

A set of patches was introduced to the kernel and
ath9k driver as well as wpa_supplicant, e.g.,

  a39e9af90 ("nl80211: DPP listen mode callback")
  4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")

However, the hostapd code itself was not calling the new multicast
registration. As such the AP side of things wasn't working as expected
in some scenarios. I've found this while trying to get ath9k working as
an AP Responder/Configurator.

The problem wasn't seen on, e.g., mac80211 hwsim driver.

Extend the wpa_supplicant mechanism to work with hostapd as well.

Signed-off-by: Michal Kazior <michal@plume.com>

src/ap/ap_drv_ops.c

@@ -988,3 +988,11 @@ int hostapd_drv_update_dh_ie(struct hostapd_data *hapd, const u8 *peer,
 	return hapd->driver->update_dh_ie(hapd->drv_priv, peer, reason_code,
 					  ie, ielen);
 }
+
+
+int hostapd_drv_dpp_listen(struct hostapd_data *hapd, bool enable)
+{
+	if (!hapd->driver || !hapd->driver->dpp_listen || !hapd->drv_priv)
+		return 0;
+	return hapd->driver->dpp_listen(hapd->drv_priv, enable);
+}

src/ap/ap_drv_ops.h

@@ -134,6 +134,7 @@ int hostapd_start_dfs_cac(struct hostapd_iface *iface,
 int hostapd_drv_do_acs(struct hostapd_data *hapd);
 int hostapd_drv_update_dh_ie(struct hostapd_data *hapd, const u8 *peer,
 			     u16 reason_code, const u8 *ie, size_t ielen);
+int hostapd_drv_dpp_listen(struct hostapd_data *hapd, bool enable);
 
 
 #include "drivers/driver.h"

src/ap/dpp_hostapd.c

@@ -697,12 +697,14 @@ int hostapd_dpp_listen(struct hostapd_data *hapd, const char *cmd)
 		return -1;
 	}
 
+	hostapd_drv_dpp_listen(hapd, true);
 	return 0;
 }
 
 
 void hostapd_dpp_listen_stop(struct hostapd_data *hapd)
 {
+	hostapd_drv_dpp_listen(hapd, false);
 	/* TODO: Stop listen operation on non-operating channel */
 }