p2p negotiation response/confirmation race condition
Wed Mar 30 10:37:22 PDT 2011
i encounter some race condition in the p2p negotiation process:
1. peerA -> peerB - negotiation request (go_intent=5)
2. peerA -> peerB - negotiation request (go_intent=5) (retry)
3. peerB -> peerA - negotiation response(go_intent=7, ssid=DIRECT-AA)
4. peerB -> peerA - negotiation response(go_intent=7, ssid=DIRECT-BB)
5. peerA -> peerB - negotiation confirmation (to (3))
now, peerA will try connecting to DIRECT-AA, while peerB starts a
group with DIRECT-BB ssid.
currently, wpa_supplicant generates a new ssid (p2p_build_ssid) on
each negotiation request processing.
the questions i have are:
1. when should we set the ssid? should the ssid be saved for each dev?
(note that we might have multiple peers trying to connect, so
generating a new global ssid on negotiation start might still race
2. what about other non-ssid elements? e.g. the same race applies for
the operating channel as well, as long as we don't take the channel
from the negotiation confirmation (currently, we just check for its
More information about the Hostap