Issue with DPP and offchan frames

[James Prestwood]

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...

[1]
https://lore.kernel.org/linux-wireless/2b18f86924c3d64437aa139f6401ee2e7705eeb0.camel@gmail.com/


> 
> 
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap