If the peer you want to connect to is no longer available (does not
acknowledge frames) when wpa_supplicant sends GO Negotition Request
frames, retransmission of this frame is done until the associated
p2p_device structure is removed on timeout. In that case, no signal
is emitted to inform the GO Negotiation has failed.
When sending an Invitation Request frame, the same retransmission
mechanism is in place but limit the transmission to 100 and hitting
the limit generates an event.
This patch adds the same mechanism as the one in place for Invitation
Request, but with limit of 120 to match the existing wait_count for
for GO Negotiation.
If there is a pending GO Negotiation when p2p_cancel is used,
unauthorize the peer to avoid immediate reconnection from being
accepted without a new p2p_connect command.
The driver wrapper may now indicate the preferred channel (e.g., based
on scan results) on both 2.4 GHz and 5 GHz bands (and an overall best
frequency). When setting up a GO, this preference information is used
to select the operating channel if configuration does not include
hardcoded channel. Similarly, this information can be used during
GO Negotiation to indicate preference for a specific channel based
on current channel conditions.
p2p_group_add command can now use special values (freq=2 and freq=5)
to indicate that the GO is to be started on the specified band.
We need to drop the pending frame to avoid issues with the new GO
Negotiation, e.g., when the pending frame was from a previous attempt at
starting a GO Negotiation.
We are not actually interested in the PD Response in join-a-group
case, so there is no point in trying to send PD Request until the
response is received. This avoids an extra PD getting started after
a join-a-group operation in some cases.
In order to avoid confusing the driver with a new remain-on-channel
request, delay sending of a new Action frame if the driver indicates
Action frame RX diromg a scan.
This is needed to optimize response to GO Negotiation Request frames.
The extra remain-on-channel cancel followed by new remain-on-channel for
the same channel takes too much time with some driver/firmware
designs for the response to go out quickly enough to avoid peer
timing out while waiting for our response.
The workaround to ignore no ctrl::ack received for GO Negotiation
Confirmation frame was only supposed to be used when the frame was
actually transmitted and just the ack was not received. However, due
to the way the driver failure on transmitting the frame were reported,
this ended up getting applied for all failures in sending the GO
Negotiation Confirmation frame.
Improve this by providing a mechanism to indicate whether send_action
operations fail locally before the frame was actually transmitted or
because of not receiving ack frame after having transmitted the frame.
If an authorized (p2p_connect used locally) GO Negotiation is
rejected when receiving GO Negotiation Request from the peer,
indicate the failure with a ctrl_interface P2P-GO-NEG-FAILURE
event. Previously, this event was only shown on the peer (i.e.,
the device receiving the GO Negotiation Response with non-zero
Status code).
Add (or complete Probe Request only) P2P peer entry when receiving
Provision Discovery Request from a previously unknown peer. This is
especially of use for a GO when a P2P client is requesting to join
a running group.
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 should not really happen, but it looks like the Listen command
may fail is something else (e.g., a scan) was running at an
inconvenient time. As a workaround, allow new Extended Listen
operation to be started if this state is detected.
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.
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.
"wpa_cli p2p_set peer_filter <MAC address>" can now be used to
only allow a single P2P Device (based on P2P Device Address) to be
discovered for testing. Setting the address to 00:00:00:00:00:00
disables the filter.
