Issue with DPP and offchan frames

[Jérôme Pouiller]

Hi James,

On Wednesday 2 February 2022 00:41:06 CET James Prestwood wrote:
> Hi Jerome,
> 
> On Tue, 2022-02-01 at 15:09 +0100, Jérôme Pouiller wrote:
> > Hi Folks,
> >
> > I encounter some difficulties to authenticate a station using DPP-PSK.
> >
> > On my setup, I have one AP (A) listening channel 1 and one station (B)
> > waiting for a DPP authentication request on channel 6 (using
> > "dpp_listen 2437"). During DPP processing, it seems that (A) send data
> > on channel 1 while (B) is still listening on channel 6.
> >
> > I use hostapd/wpa_supplicant 2.9 (if necessary I could try with 2.10).
> >
> > The capture in attachment has been done on channel 6 under an RF
> > isolated environment. Address of (A) is 00:0c:ca:98:0a:90 and address
> > of
> > (B) is 00:0c:ca:97:83:1f.  The capture starts after I executed
> > 'dpp_auth_init peer=1 conf=sta-psk ssid=XXX pass=XXX' on (A). It is
> > also
> > worth to note the signal strength of each station received by the
> > monitor:
> >   (A) on channel 1:  -35dBm
> >   (A) on channel 6:   -3dBm
> >   (B) on channel 1:  -48dBm
> >   (B) on channel 6:  -12dBm
> >
> > We can see the following sequence on channel 6:
> >   DPP - Authentication Request
> >   DPP - Authentication Response
> >   DPP - Authentication Confirm
> >
> > Then, (A) continue to send a few beacons on channel 6 (maybe this
> > behavior is not expected, but it is not my point here).
> >
> > Then (A) leaves channel 6 and comes back on channel 1. (B) is still
> > listening on channel 6. Finally, the authentication success because
> > channels 1 and 6 are close enough, and the signal is very strong. I
> > think that (A) should send the next frame on channel 6 (but, it didn't
> > check the specification).
> >
> >
> > I have also retrieved the debug out put of hostapd (also in
> > attachment).
> > Hostapd explicitly sends the last frame of channel 1 instead of channel
> > 6:
> >
> >   nl80211: Send Action frame (ifindex=6, freq=2412 MHz wait=0 ms
> > no_cck=0)
> >   nl80211: send_mlme - da= 00:c0:ca:97:83:1f noack=0 freq=2412 no_cck=0
> > offchanok=1 wait_time=0 fc=0xd0 (WLAN_FC_STYPE_ACTION) nlmode=3
> 
> TL;DR; Good luck :)
> 
> I don't know enough about hostapd/wpa_supplicant to know in if this is
> a bug per-se, but the wireless subsystem in the kernel is downright
> awful with offchannel handling. Coupled with the fact that the DPP spec
> completely botched how devices discover each other you're going to need
> a lot of luck to get DPP to work nicely.
> 
> Starting with the wireless subsystem, the problem is you can only go
> offchannel for a pre-determined duration. Once the duration is over the
> device goes idle and you must issue an offchannel request again. This
> leaves some amount of time where the device is ignoring all incoming
> frames. In addition the duration _you_ choose is left up to the driver.
> Some may choose a different, shorter, duration which only adds to the
> problem.
> 
> As far as the DPP spec is concerned they define the 'presence'
> procedure, aka 'discovering your peer'. If you are to follow the spec
> (which wpa_supplicant/hostapd do) one peer first gathers a list of
> channels advertised in the URI (no maximum), then adds on two default
> channels, then scans for and APs advertising a special IE. This
> potentially results in a list of MANY channels. The device then hops
> between channels sending announcements and waiting for a reply. The
> other peer does a similar procedure hopping between channels waiting to
> find the other peer.
> 
> If it hasn't become blatantly obvious its going to take a LONG time for
> these peers to be on the same channel at the same time, if ever.
> 
> I've expressed my concern with the kernel [1], and suggested a solution
> but nothing has come of it yet. Johannes seemed to think there was no
> way without setting an internal timer, which doesn't solve anything.
> Arend seemed to think we could do it, but I haven't heard back.
> 
> With IWD we chose to go off-spec for the presence procedure and only
> use channels listed in the URI or a default list of two channels. When
> IWD is building a URI it only sets a single channel. This makes things
> a lot better, at least when using IWD...

I haven't heard news about iwd for a while. I'm glad to hear the
development is going right.

Anyway, I have the expected result if I hard code de frequency in
gas_serv_req_dpp_processing():


diff --git a/src/ap/gas_serv.c b/src/ap/gas_serv.c
index 90f15778b..077d8c0bf 100644
--- a/src/ap/gas_serv.c
+++ b/src/ap/gas_serv.c
@@ -1582,7 +1583,7 @@ void gas_serv_req_dpp_processing(struct hostapd_data *hapd,
                return;
        if (prot)
                convert_to_protected_dual(tx_buf);
-       hostapd_drv_send_action(hapd, hapd->iface->freq, 0, sa,
+       hostapd_drv_send_action(hapd, 2437, 0, sa,
                                wpabuf_head(tx_buf),
                                wpabuf_len(tx_buf));
        wpabuf_free(tx_buf);


Obviously, the correct frequency is hapd->dpp_auth->curr_freq. Unfortunately,
hapd->dpp_auth is NULL when gas_serv_req_dpp_processing() is called.

I tried to understand why hapd->dpp_auth is NULL. It seems it's related to
the order in which hostapd_dpp_relay_gas_resp_tx() and
hostapd_dpp_gas_status_handler() are called. But, it starts to be complex
for me.

-- 
Jérôme Pouiller