The overlap condition cannot disappear before group formation timeout
hits, so there is no point in continuing in this case and failure can
be indicated immediately.
This allows the pending group interface to be removed if we fail
to join a running group. A longer than 15 second timeout is needed
here since the GO may not have authorized our connection yet.
The scan operation before Provision Discovery Request may not include
the GO. However, we are likely to have the GO in our P2P peer table,
so use that information to figure out the operating channel if BSS
table entry is not available.
This is needed to make sure we do not try to accidentally enable GO
in channels that may not be allowed. In addition, this may help with
some driver that do not like channel 14 even as a passive scan
channel.
This event indicates the Device Password ID that the peer tried
to use in GO Negotiation. For example:
P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7 dev_passwd_id=4
If enabled, cross connection allows GO to forward IPv4 packets
using masquerading NAT from the P2P clients in the group to an
uplink WLAN connection. This is disabled by default and can be
enabled with "wpa_cli p2p_set cross_connect 1" on the P2P device
interface.
For now, this applies to the test command that can be used to set
periodic NoA (p2p_set noa). The value are stored and periodic NoA
is enabled whenever there are no non-P2P STAs connected to the GO.
While this is not strictly speaking required by the P2P specification
for a not-P2P Managed Device, this can provide useful information for
the P2P manager AP and may be needed to pass certification tests.
For client-invites-device case, the pre-authorization of an invitation
to running group will need to allow Invitation Request from specified
address, too. This is for testing uses only.
This is mainly designed for testing and allows p2p_connect join auth
to be used to accept a specific invitation to an active group that
may be received in the future.
The driver event for remain-on-channel may be delayed in a way that
allows management-frame-received event to be received before
wpa_supplicant knows that the driver is actually already on the
previously requested channel. We should not request a new
remain-on-channel to send a response to just a frame if we are waiting
for the driver to get to the same channel. Instead, just continue
waiting for the driver event.
When the first wpa_supplicant interface is not the correct one for
transmitting an Action frame (e.g., P2P Presence Request frame
uses a group interface), the code got stuck in an infinite busy
loop. Fix the iteration to go through the interfaces properly.
