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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
