We can automatically accept invitations that are for a persistent
group that is already running. There is no need to confirm this
separately or preparare a new group interface.
When an Invitation to reinvoke a persistent group is accepted,
we need to make sure that any pending p2p_find or p2p_listen
operation gets stopped to avoid consuming all radio resources
doing device discovery while the group is being set up.
This pointer is now used in number of places to check whether an
interface is in P2P Group Formation, so we better make sure it gets
cleared when group formation has been completed. This was done in
only some of the cases.
The pending_invite_ssid_id of -1 (running group, not persistent) was
being stored incorrectly in the group interface, not device interface
(i.e., parent of the group interface) and consequently, the incorrect
information was used when processing the Invitation Response.
If there was a persistent group credentials stored with network id
0, those were used instead to try to set up a persistent group
instead of using the already running group.
Since the P2P peer entry may not have been available at the time the
join request was issued, we need to allow the P2P Interface Address
to be updated during join-scans when the P2P peer entry for the GO
may be added.
If the GO is not found, we cannot send Provisioning Discovery Request
frame and cannot really connect anyway. Since the Provisioning
Discovery is a mandatory part, it is better to continue join-scan
until the GO is found instead of moving to the next step where
normal connection scan is used (PD would not be used from there).
Use a limit of 10 scan attempts for p2p_connect join to avoid getting
in infinite loop trying to join. If the GO is not found with those
scans, indicate failure (P2P-GROUP-FORMATION-FAILURE) and stop the
join attempt.
When running "p2p_connect addr pbc join" command, send the
WPS-OVERLAP-DETECTED even also to the parent interface (i.e.,
the one on which the p2p_connect was issued) and not only the
group interface in case separate P2P group interfaces are used.
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.
The driver may end up leaving the current channel when we request
a new remain-on-channel and as such, it is better not assume we can
start new operations like sending an Action frame on the previous
off-channel.
If we have already asked the driver to start a new remain-on-channel,
we need to cancel it even if the actual remain-on-channel has not yet
started at the point when a new operation or timeout etc. triggers
Listen state to be stopped.
Even if p2p_scan_res_handler() returns 1 to indicate that scan result
iteration should be stopped, the p2p_scan_res_handled() needs to be
called to clear p2p_scan_running and to get a callback that will start
any operations that were delayed because of the running scan.
There is no need to separately move to the correct channel
for transmitting an Action frame that is using the group
interface (i.e., source address is P2P Interface Address).
This removes extra latency from P2P Action frame operations
within a P2P group.
This could have been using an uninitialized variable instead of
purposefully random value in picking up the channel. There is not
much of a difference for the use case here, but anyway, we may
as well do what was initially planned here and.
Add a new driver event, EVENT_INTERFACE_UNAVAILABLE, for indicating
that the driver is not able to continue operating the virtual
interface in its current mode anymore, e.g., due to operating
channel for GO interface forced to a DFS channel by another virtual
interface.
When this happens for a P2P group interface, the P2P group will
be terminated and P2P-GROUP-REMOVED event shows the reason for
this as follows:
P2P-GROUP-REMOVED wlan0 GO reason=UNAVAILABLE
A new configuration parameter, p2p_group_idle, can now be used to set
idle timeout value for P2P groups in seconds (0 = no timeout). If set,
this values is used to remove P2P group (both GO and P2P client)
interfaces after the group has been idle (no clients/GO seen) for the
configuration duration.
The P2P-GROUP-REMOVED event is now indicating the reason for group
removal when known. For example:
P2P-GROUP-REMOVED wlan0 GO reason=REQUESTED
P2P-GROUP-REMOVED wlan1 client reason=IDLE
The P2P group component is now tracking of associated stations
in the group and the Group Limit bit in the Group Capabilities
is updated based on whether there is room for new clients in
the group.
This driver capability limit was supposed to indicate limit on
how many stations can associate with us in the AP mode, not how
many P2P peers are stored in the peer table.
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.
This is needed to work around cases where the pending interface gets
removed, e.g., due to failed GO Negotiation. In such case, we may still
accept new GO Negotiation to be completed, but the interface did not
get created without a separate p2p_connect command.
The current implementation is not ideal since the re-created interface
may, at least in theory, get incorrect interface addrees. Though, this
would likely require that the driver supported more than one P2P group
interface and that the previous one was already taken into use for
another group.
The driver wrapper can now indicate whether the driver supports
concurrent operations on multiple channels (e.g., infra STA connection
on 5 GHz channel 36 and P2P group on 2.4 GHz channel 1). If not,
P2P_CONNECT commands will be rejected if they would require
multi-channel concurrency.
The new failure codes for P2P_CONNECT:
FAIL-CHANNEL-UNAVAILABLE:
The requested/needed channel is not currently available (i.e., user has
an option of disconnecting another interface to make the channel
available).
FAIL-CHANNEL-UNSUPPORTED:
The request channel is not available for P2P.
Allow only the expected P2P Interface Address as the BSSID for
the AP to avoid selecting incorrect BSS should there be another
device that is advertising active PBC mode before the target
P2P GO does.
When the P2P state machine requests a remain- on-channel, there's a
potential race where it can then request a stop before the r-o-c has
actually started, in which case the stop will not be processed. Fix
that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
WPS 2.0 mandates the AP to include WPS IE in (Re)Association Response
if the matching (Re)Association Request included WPS IE. Provide the
needed WPS IE information to the driver_ops API for drivers that
process association frames internally.
Note: This modifies the driver_ops API by adding a new argument to
set_ap_wps_ie().
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.
