DPP PKEX and retransmissions

[James Prestwood]

Hi,

After adding PKEX support to IWD and testing against wpa_supplicant I 
noticed some unexpected and limiting behavior in the wpa_supplicant 
implementation.

First it appears the wpa_supplicant only supports retransmitting the 
PKEX exchange request. This is a bit strange since its a broadcast so 
you should never see the no-ACK flag for this. Adding retransmissions to 
other frames is obviously an additional feature and isn't required by 
the spec but I just figured I'd point that out.

Second, and more importantly, it does not handle the case of a peer not 
receiving the PKEX exchange response (no-ACK set in TX-STATUS). The 
following situation gets wpa_supplicant into a state where it will not 
accept any PKEX exchange requests, since it already received one:

  - Start wpa_supplicant PKEX as responder
  - wpa_supplicant receives PKEX exchange request, sends response
  - Peer does not ack, TX-STATUS has no-ACK flag set.
  - Peer sends another PKEX exchange request but wpa_supplicant ignores 
since it thinks there is an ongoing PKEX exchange.

This actually seems like a common case to hit due to the 200ms wait 
requirement and how offchannel works in the kernel. A peer is going to 
be iterating some list of frequencies and only dwelling for 200ms on 
channel. If wpa_supplicant receives the exchange request but the peer 
left the channel before the response was sent you could get into this 
situation. It seems like wpa_supplicant should reset _something_ when it 
gets a no-ACK TX-STATUS having only sent the PKEX response?

Thanks,
James