The BSS table, scan timeout, and related functionality should use
monotonic time since they care about relative values (age) only.
Unfortunately, these are all connected, so the patch can't be split
further. Another problem with this is that it changes the driver wrapper
API. Though, it seems only the test driver is using this.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Based on priority, remove the connection with least priority whenever
a frequency conflict is detected.
Signed-hostap: Jithu Jance <jithu@broadcom.com>
This field allows adds enough information into the P2P-DEVICE-FOUND
events to figure out if the peer supports Wi-Fi Display.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
The shorter 250 ms wait for the next scan request can be used also for
the case of persistent group re-invocation instead of just formation of
a new group. This speeds up the process and makes this more robust
especially in cases where the GO is using MCC.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Only force_freq was used in the wpas_p2p_set_own_freq_preference() call
which allowed the P2P module channel re-selection to ignore the
preference for using a channel we are already using. Fix this by setting
either force_freq or pref_freq as the preference based on which one is
set. This allows p2p_ignore_shared_freq parameter to be used whether to
prefer the shared frequency in this case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
There is no need to use wpas_p2p_num_unused_channels() here in the
default configuration of p2p_ignore_sahred_freq=0, so re-order the
conditions to skip that operation. This is a bit more efficient and the
debug log is also a bit cleaner in the default case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_ignore_shared_freq=1 was supposed to allow a MCC-capable device to
ignore a preference for using the same channel on multiple interfaces.
However, it was not used when inviting a peer to re-invoke a persistent
group. This case needs special handling since the peer's channel list is
not available to perform channel reselection and the operating channel
indicated in the Invitation Request frames ends up getting used as the
operating channel if the transmitted of that frames becomes the GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_ignore_shared_freq=1 was supposed to allow a MCC-capable device to
ignore a preference for using the same channel on multiple interfaces.
However, it was not used during processing of an Invitation Request. Fix
that case to use channel preference instead of channel forcing if free
channels are available. This allows p2p_ignore_shared_freq=1 case to
ignore the preference.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It is confusing to talk about current operating channels being
unavailable for P2P when there are no current operating channels. Make
the debug message easier to understand.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It is clearer if there is only a single loop of the channel list and
shared debug prints. In addition, the note about current operating
channels not being available is quite confusing if there are no
operating group, so make that part of the message conditional.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 0d08efa447 modified
wpas_p2p_setup_freqs() design to use number of MCC channels capability
from the driver. However, it resulted in regression on how the preferred
vs. forced channel selection is done in the case of a MCC device.
force_freq was set unconditionally even though this was supposed to be
done only if no additional channels are available. pref_freq needs to be
used when possible to avoid preventing connection.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
During persistent group re-invocation, GO may end up using a different
channel as the operation channel compared to what was indicated in the
invitation frames. This may break the connection if the peer device ends
up scanning the GO only on the channel from the invitation frame. Fix
this by using the negotiated channel (if available) on the GO as the
operating channel instead of the channel that was provided in the
p2p_invite command to start negotiation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This prints out get_shared_radio_freqs() results and related information
from P2P operations to make debug logs more helpful for figuring out
issues related to multi-channel concurrency.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When trying to choose a frequency that can be used for GO instantiation,
properly check if there are free channels that can be used.
Signed-hostap: Ilan Peer <ilan.peer@intel.com>
It was possible for the wpa_s->show_group_started and wpa_s->go_params
to be left set when a P2P group was removed before group formation had
completed. In case a separate P2P group interface was not used, this
could rsult in all future scans using the hardcoded DIRECT-* SSID and as
such, not find the network they were trying to find. Fix this by
clearing these P2P parameters on group removal.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Start GO with VHT support if VHT option was requested
and the appropriate channels are available.
Signed-hostap: Eliad Peller <eliadx.peller@intel.com>
Add the option to ask for VHT operation similarly to the way ht40 is
configured - either by adding 'vht' param to the relevant p2p_*
commands or by configuring p2p_go_vht=1 in the configuration file.
This patch only adds the configuration option (e.g., via control
interface). The actual handling of the VHT parameter (asking the driver
to use VHT, etc.) will be done by the following patch.
Signed-hostap: Eliad Peller <eliadx.peller@intel.com>
The new p2p_add_cli_chan=1 configuration parameter can be used to
request passive-scan channels to be included in P2P channel lists for
cases where the local end may become the P2P client in a group. This
allows more options for the peer to use channels, e.g., if the local
device is not aware of its current location and has marked most channels
to require passive scanning.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The new p2p_no_go_freq frequency range list (comma-separated list of
min-max frequency ranges in MHz) can now be used to configure channels
on which the local device is not allowed to operate as a GO, but on
which that device can be a P2P Client. These channels are left in the
P2P Channel List in GO Negotiation to allow the peer device to select
one of the channels for the cases where the peer becomes the GO. The
local end will remove these channels from consideration if it becomes
the GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 2e5ba4b6d1 moved this to a function
and updated one of the os_snprintf() calls to use the len parameter, but
forgot the other one.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When a GO or P2P Client invites a peer device to join an already
operating group, the Operating Channel in Invitation Request needs to be
forced to the current operating channel of the group.
Signed-hostap: Jouni Malinen <j@w1.fi>
This makes it easier to debug issues related to selecting GO information
from the latest updated BSS table entry.
Signed-hostap: Jouni Malinen <j@w1.fi>
P2P IE may be available from a Beacon frame from a GO even if we have
not yet received a Probe Response frame with P2P IE from that GO. Since
all the needed information for determining the GO's P2P Device Address
and group capabilities are available, use that information instead of
displaying incomplete group information.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This fixes some P2P-join-a-group cases where GO may have been discovered
based on passive scan or non-P2P scan. P2P IEs may have been received
from a Beacon frame in such a case and that information can be used to
create a P2P peer entry, e.g., to allow provision discovery exchange to
be completed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If a group was removed before the wait for the first client had timed
out and the client had not yet connected, p2p_go_wait_client could have
been left set and with that, scan operations could be unnecessarily
delayed. This fixes some undesired delays from commit
c1c0b35fea.
Signed-hostap: Jouni Malinen <j@w1.fi>
Commit 41f853235f extends group formation
timeout for the first data connection to complete and resets
p2p_go_group_formation_completed flag due to which p2p_in_provisioning
and p2p_group_formation flags are not cleared when
wpas_group_formation_completed() is called. This can result in both
station scan and p2p_find failures in the case where separate P2P group
interface is not used and the client does not complete 4-way handshake.
Fix this by clearing p2p_group_formation and p2p_in_provisioning when
such a P2P group is deleted.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Update the p2p_go_wait_client timestamp in p2p_go_configured() to
address the case where the group is set up without the provisioning
step.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, GO considered the group to be fully re-invoked after
starting beaconing on successful invitation exchange. This would leave
the group running until idle timeout (which may not be enabled) or
explicit removal if the client fails to connect for any reason. Since
the client is expected to connect immediately after the invitation
exchange that ends with status=0 (i.e., either client initiated the
exchange or it responded with success), extend group formation timeout
to cover that period until the first successfully completed data
connection. This allows the GO to remove the group automatically if the
client devices does not connect within
P2P_MAX_INITIAL_CONN_WAIT_GO_REINVOKE (15) seconds.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, GO considered the group to be fully formed at the completed
of WPS provisioning step. This would leave the group running until idle
timeout (which may not be enabled) or explicit removal if the client
fails to connect for any reason. Since the client is expected to connect
immediately after the WPS provisioning step, extend group formation
timeout to cover that period until the first successfully completed data
connection. This allows the GO to remove the group automatically if the
client devices does not connect within P2P_MAX_INITIAL_CONN_WAIT_GO (10)
seconds.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It was possiblle for the group formation timeout to be left running even
after the P2P Client connected to the group if the WPS provisioning step
was not completed cleanly (e.g., due to WSC_Done not getting received
from the client). There is no need to remove the group in such case due
to the initial group formation timeout, so work around this by removing
that timeout on data connection.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
wpa_supplicant crashes if driver configuration for AP mode interface
configuration fails after group negotiation. This is because of a
regression from commit 1075b29571 that
ends up freeing the wpa_s instance from within
wpa_supplicant_create_ap() without the caller knowing.
Fix this by using an eloop timeout to free remove the P2P group so that
wpa_supplicant_create_ap() and especially wpa_supplicant_associate()
callers do not need to know about interface getting possibly removed. In
addition, move the P2P specific code into p2p_supplicant.c where it
really belongs. This allows the already existing group formation timeout
to be used by reducing the timeout to zero.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Avoid potential issues with removing a P2P group on PSK failure directly
from the wpa_supplicant_event() call since the caller (in driver_*.c)
may not be prepared for the interface disappearing at that point in
time.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for the GO of a persistent group to change the PSK or
remove a client when per-client PSKs are used and this can happen
without the SSID changing (i.e., the group is still valid, but just not
for a specific client). If the client side of such persistent group ends
up trying to use an invalidated persistent group information, the
connection will fail in 4-way handshake. A new WPS provisioning step is
needed to recover from this.
Detect this type of case based on two 4-way handshake failures when
acting as a P2P client in a persistent group. A new
"P2P-PERSISTENT-PSK-FAIL id=<persistent group id>" event is used to
indicate when this happens. This makes it easier for upper layers to
remove the persistent group information with "REMOVE_NETWORK <persistent
group id>" if desired (e.g., based on user confirmation).
In addition to indicating the error cases for persistent groups, all
this type of PSK failures end up in the client removing the group with
the new reason=PSK_FAILURE information in the P2P-GROUP-REMOVED event.
Signed-hostap: Jouni Malinen <j@w1.fi>
If a client joins a P2P group multiple times, replace the previous
per-client PSK entry instead of adding a new entry each time.
Signed-hostap: Jouni Malinen <j@w1.fi>
The new control interface command P2P_REMOVE_CLIENT <P2P Device
Address|iface=Address> can now be used to remove the specified client
from all groups (ongoing and persistent) in which the local device is a
GO. This will remove any per-client PSK entries and deauthenticate the
device.
Signed-hostap: Jouni Malinen <j@w1.fi>
Record all generated per-client PSKs in the persistent group network
block and configure these for the GO Authenticator whenever re-starting
the persistent group. This completes per-client PSK support for
persistent groups.
Signed-hostap: Jouni Malinen <j@w1.fi>
Even after listen duration is over, P2P module remained in
P2P_LISTEN_ONLY state, which is blocking station mode scans. Fix this by
stopping P2P listen explicitly to update p2p_state to IDLE when listen
duration expires.
Signed-hostap: Syed Asifful Dayyan <syedd@broadcom.com>
By default, P2P is initialized for all driver interfaces and this makes
P2P getting initialized for non-P2P station interface if the supplicant
is started first on this interface. If an interface is dedicated for
non-P2P station mode, it is now possible to disable P2P initialization
by adding 'p2p_disabled=1' in the configuration file of non-P2P station
interface, irrespective of the order in which supplicant is started.
Signed-hostap: Sreenath Sharma <sreenats@broadcom.com>
Previously, concurrent station mode scans were postponed during an
ongoing P2P group formation up to the point of completed WPS
provisioning step. This would allow a scan to be started before the P2P
client has completed association for the data connection if a scan
request were timed to hit the window between the provisioning step and
the following association. Avoid this by extending P2P-in-progress state
to continue until the first data connection has been completed as part
of group formation. Use a ten second timeout for this to avoid leaving
scans disabled indefinitely if the client fails to connect completely.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This provides status information about the negotiated group to
wpa_supplicant control interface monitors during group formation in a
form that is easier to use than having to fetch the information
separately.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When 'p2p_group_remove *' is called while the station interface
is connected, the flow also disconnects the station interface.
Fix this by skipping non-P2P interfaces in the iteration.
Signed-hostap: Ilan Peer <ilan.peer@intel.com>
This reverts commit ce970851af.
It turned out that this breaks lots of use cases where p2p_find is
issued while already in p2p_listen state. As such, we cannot reject
p2p_find this easily without checking for more specific cases.
Signed-hostap: Jouni Malinen <j@w1.fi>
Though p2p_find is not expected during ongoing P2P connection, it is
possible that any third party application issues a p2p_find resulting in
connection failure. Address this by rejecting any p2p_find command while
connection is in progress.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Change the P2P flows to use the number of concurrent channels
supported by the device and the number of currently used channels
for the P2P flows.
Signed-hostap: Ilan Peer <ilan.peer@intel.com>
Signed-hostap: David Spinadel <david.spinadel@intel.com>
There is no need to wait for the 15 second group formation timeout
before indicating P2P group formation failure if GO mode cannot be
started successfully for some reason.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
