Save the group common frequencies when starting a GO due to
an invitation signaling requesting to re-invoke a persistent GO.
To do so, move the code that handles the translation of p2p_channels to
frequency list into a public function so it can be re-used both when GO
Negotiation is done and invitation signaling is done.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Once a P2P GO interface is configured, save the group common
frequencies, as this can be useful later for channel selection
considerations during channel switch, etc.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Use the 'no_ir' notation instead of the 'passive scan' and
'no_ibss' notations to match the earlier change in nl80211.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
The extra_roc_dur parameter can now be used in CONFIG_TESTING_OPTIONS=y
builds to simulate driver behavior where the ROC duration gets increased
without user space request.
Signed-off-by: Jouni Malinen <j@w1.fi>
When GC receives invitation response and tries to re-establish
connection to a persistent group channels from passive list should
be allowed. A missing check for operation mode triggered reselection
of operating channel from active channels only to happen and thus fail
the connect attempt.
Add a check for operation mode and if GC instead use negotiated
frequency (i.e. GO operating channel from invitation response).
Signed-off-by: Mikael Kanstrup <mikael.kanstrup@sonymobile.com>
Commit 1595eb93ae ('P2P: Add support for
60 GHz social channel') had an unintended change to how P2P search scans
2.4 GHz social channels. Use of p2p_supported_freq() to filter the list
of social channels ended up using the disallow_freq setting to remove
social channels from the P2P search scans. This is not desired since
peers need to be found on any of the social channels even if those
channels have been disabled from P2P operating channel use. Restore the
previous behavior by included all the 2.4 GHz social channels in P2P
search scans if the driver indicated support for the 2.4 GHz band.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This is needed to allow dynamic removal of an interface that adds the
P2P Device interface without leaving behind the management interface
with invalid wpa_s->parent pointer.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was possible to issue the P2P_GROUP_REMOVE command through the
per-interface control interface. This resulted in freed memory getting
accessed when trying to send the control interface response to the
operation that ended up deleting the group interface. Fix this by
postponing the removal operation until the caller has returned.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 152cff6ba6 ('P2P: Remove
WPA_DRIVER_FLAGS_P2P_MGMT option') removed the only non-zero return from
wpas_p2p_stop_find_oper(), but did not remove the useless return value
or the return check in wpas_p2p_stop_find(). Clean these up by removing
unreachable code and useless return value.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
This information can be used to determine whether the event is generated
for a new peer that was added or due to an update in the information for
an existing peer.
Signed-off-by: Jouni Malinen <j@w1.fi>
len + pos > end comparison here did verify that the length field had a
valid value, but that did not seem to enough to avoid TAINTED_SCALAR
warning. Re-order that validation step to be equivalent "len > end -
pos" to remove these false positives (CID 68116).
Signed-off-by: Jouni Malinen <j@w1.fi>
A P2P Client may be able to connect to the GO even if the WPS
provisioning step has not terminated cleanly (e.g., P2P Client does not
send WSC_Done). Such group formation attempt missed the event
notification about started group on the GO and also did not set the
internal state corresponding to the successful group formation.
This commit addresses the missing part by completing GO side group
formation on a successful first data connection if WPS does not complete
cleanly. Also, this commit reorders the STA authorization indications to
ensure that the group formation success notification is given prior to
the first STA connection to handle such scenarios.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, this variable did not necessarily get cleared between group
formations and could result in some of the workaround operations from
not being executed after the first group formation when using the same
interface for all P2P groups. Fix this by clearing the variable whenever
starting the GO to make sure it is used consistently for each group
formation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for group formation timeout to be the trigger for
detecting the second PSK/4-way handshake failure. If that happened, the
special reason=PSK_FAILURE was not used in the P2P-GROUP-REMOVED event
even though P2P-PERSISTENT-PSK-FAIL did get reported. Fix this special
case by replacing the reason code with PSK_FAILURE if the PSK failure
timeout gets registed as part of the disconnection processing in the
formation timeout handler.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, the case of non-netdev P2P management device ended up
pulling in both the main interface (e.g., wlan0) and P2P Device
interface (from command line -m argument) as configuration. Similarly,
the main interface ended up included both configuration files. This is
not really helpful for various use cases, e.g., when permanent P2P group
information is stored in the P2P Devince interface, but it gets
duplicated in the main station interface configuration.
Clean this up by changing the -m<file> argument to replace, not
concatenate, configuration information. In other words, the main station
interface will not read this configuration and the P2P Device interface
(non-netdev) does not read parameters from the station interface
configuration file.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Support 60 GHz band in P2P module by selecting random social channel
from all supported social channels in 2.4 GHz and 60 GHz bands.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This check is already being done on wpas_p2p_deinit_iface.
Of course, it is assumed wpa_s is not deinit when reaches
that point as a matter of fact.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
As P2P service are not necessarily attached to a iface, when
added, proceed with same approach on p2p global deinit. Such
approach solves memory leaks ocurring upon wpa_supplicant
termination, when p2p services were registered previously.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
In theory, this call could fail, so check the return value before using
the received data. These specific cases would not really care much about
the failures, but this keeps the code more consistent and keeps static
analyzer warnings more useful. (CID 72678, CID 72679, CID 72680,
CID 72683, CID 72689, CID 72698, CID 72703)
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently to signal PropertiesChanged upon group client
removal (group property), wpa_supplicant dbus uses wpa_s
members like go_dev_addr and current_ssid, for instance.
Thus, deferring p2p client deauth to after dbus notify,
but keeping the same order as before, solves the issue,
as wpa_s is not yet completely deinitialized.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
While building Association Request frame IEs we should consider adding
P2P IEs only on interface where P2P functionality is enabled. Consider
per interface p2p_disabled parameter before adding P2P IEs to complete
the checks for this.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, the P2P Interface Address of the peer gets updated in the
peer table every time based on the scan results.
For example, in a two port concurrency scenario, where the peer device
has two interfaces with unique P2P Interface Addresses and with same P2P
Device Address, based on the Probe Response/Beacon frames from these two
interfaces, their peer table gets updated, but each of these updates
happens in the peer table only based on the P2P Device Address. So, the
same peer's P2P Interface address is updated every time and hence, at
any instant, only one P2P Device Address to P2P Interface Address
mapping entry exist in the peer table for the peer which has two
interfaces.
When we try to join a group operated by the peer, lookup happens in the
peer table and when an interface entry is not available, the pending
interface address gets overwritten with the P2P Device Address and hence
the P2P connection can fail. Since the BSS table is the one that is
up-to-date, this fix will ensure that the interface overwriting will
happen only when there is no BSS entry for the pending P2P Interface
Address as well.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
In order to find a GO interface, there has to be a
comparison among two SSIDs, instead of a wpa_ssid and
a ssid.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
When p2p_cancel is invoked while the GO Negotiation Action TX was
pending, the p2p_send_action_work was not getting cleared.
Signed-off-by: Jithu Jance <jithu@broadcom.com>
The PSK/passphrase are needed for the control interface events since the
upper layer UI component is required by the specification to be able to
make this available for manual configuration. However, this is not
needed in the INFO verbosity level debug entry, so split the event
generation into two parts.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it easier to change the event message message for indication
when P2P group has stated and removes some duplicated code.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows external programs to use vendor specific information from
P2P peers without wpa_supplicant having to be able to parse and
understand all such vendor specific elements.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This would not really be needed since these functions check the pointer
above. However, this seems to be too difficult for some static analyzer,
so add the extra check to avoid false reports.
Signed-off-by: Jouni Malinen <j@w1.fi>
This will be useful for a peer to know if it is part of a group either
as a client of our local GO or as the peer GO.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Previously, eight character random passphrase was generated
automatically for P2P GO. The new p2p_passphrase_len parameter can be
used to increase this length to generate a stronger passphrase for cases
where practicality of manual configuration of legacy devices is not a
concern.
Signed-off-by: Jouni Malinen <j@w1.fi>
This removes number of unnecessary #ifdef CONFIG_P2P blocks from generic
code by hiding the conditional build into p2p_supplicant.h with empty
inline functions.
Signed-off-by: Jouni Malinen <j@w1.fi>
Performing a P2P Device flow such as p2p_listen or
p2p_find, can degrade the performance of an active interface
connection, if the listen frequency is different than the
frequency used by that interface.
To reduce the effect of P2P Device flows on other interfaces,
try changing the listen channel of the P2P Device to match the
operating channel of one of the other active interfaces. This change
will be possible only in case that the listen channel is not forced
externally, and will be delayed to a point where the P2P Device
state machine is idle.
The optimization can be configured in the configuration file and
is disabled by default.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
In case there is no preference for the GO operating channel,
try using one of 1, 6, 11 (randomly), and only if the random
selection is not suitable traverse all the channels 1..11.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When the number of frequencies supported by the kernel is bigger than
one, and there is a need to pick a frequency for a new flow such as P2P
GO Negotiation or P2P Invitation, the flow should be able to pick the
best frequency among all the frequencies currently used by the device.
In order to prioritize between the currently used frequencies, add
the ability to collect additional data about each used frequency
(if the frequency is used by a station interface or P2P Client)
and when needed select the best frequency, where:
1. Infrastructure interfaces have highest priority
2. P2P Client interfaces have higher priority over AP/GO
interfaces.
The rational is that the frequency of an AP/GO can change while
that of a station interface cannot.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
This makes the p2p_find default delay value configurable as
p2p_search_delay parameter through the configuration file (and through
control interface "SET p2p_search_delay <value>" on the P2P management
interface.
This parameter controls the number milliseconds of extra delay that is
added between search iterations when there is a concurrent operation in
progress. This can be used, e.g., p2p_search_delay=100 to make p2p_find
friendlier to concurrent operations by avoiding it from taking 100% of
the radio resources. The default value is the previous default, i.e.,
500 ms. Smaller values can be used to find peers more quickly at the
cost of larger effect to concurrent operations while a larger value
leaves more time for the concurrent operations at the cost of making
device discovery take longer time.
The optional p2p_find delay argument can still be used to override the
search delay for each search operation.
Since the P2P_CONCURRENT_SEARCH_DELAY macro is not used anymore, the
driver specific build parameter for bcmdhd from Android.mk is also
removed. Similar configuration can now be achieved with
p2p_search_delay=0 in the p2p0 interface configuration file.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes the operations more consistent when going through multiple
persistent group re-invocation sequences in a row. Each invitation needs
to be accepted separately if persistent reconnect is not enabled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like there was a possible sequence for wpa_s->scan_req to be
MANUAL_SCAN_REQ at the moment a GO is to be started. This could result
in the "Request scan (that will be skipped) to start GO" to actually not
skip the scan and end up stuck waiting for something external to trigger
a scan before the GO could be started. Fix this by clearing
wpa_s->scan_req when deciding to start the GO.
This issue could be hit at least by first enabling autoscan and then
issuing P2P_GROUP_ADD. Other sequences that set wpa_s->scan_req to
MANUAL_SCAN_REQ without going through wpa_supplicant_scan() to clear it
immediately could also have similar effect (and there is even a small
window for the wpa_supplicant_scan() call to happen only after the
P2P_GROUP_ADD command is processed, so this could potentially have
happened even with SCAN + P2P_GROUP_ADD).
Signed-off-by: Jouni Malinen <j@w1.fi>
On receiving CHANNEL_LIST_CHANGED event from driver, verify that local
GO (if any) is operating in valid frequency. If not, we should remove
the group and reform on valid frequency. Indicate this similarly to the
avoid-frequency notification (i.e., a control interface message for
upper layers to react to this for now; potentially CSA later).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Do not perform extended listen period operations when either a P2P
connection is in progress. This makes the connection more robust should
an extended listen timer trigger during such an operation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previous check for dl_list_len() or having an entry from the list is
sufficient, but some static analyzers cannot figure out that
dl_list_first() and dl_list_last() will return non-NULL in this type of
cases. Avoid invalid reports by explicitly checking for NULL.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 41d5ce9e0b added scan optimizations
for P2P invitation cases. However, it left a path where the invitation
state was not cleared and as such, introduced potential issues for
following scans that ended up getting incorrectly optimized for a single
channel regardless of parameters. Fix this by clearing p2p_in_invitation
more carefully, especially on p2p_cancel command.
p2p_cancel is now also run from the FLUSH command to avoid issues with
hwsim test cases (e.g., persistent_group_per_sta_psk followed by
ap_open_tdls resulted in an error due to p2p_in_invitation remaining set
after FLUSH).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If a separate P2P group interface is used, PBC overlap during group
formation causes the group interface to be removed, which ends up with
the interface context becoming invalid. Fix this by scheduling a timeout
to process the PBC overlap and interface removal instead of removing the
interface directly before the connection operation has returned.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Use P2P group formation timeout to wait for the 4-way handshake to
complete on a persistent reinvocation on a P2P Client.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Scan for GO on the negotiated operating channel for few iterations
before searching on all the supported channels during persistent group
reinvocation. In addition, use the already known SSID of the group in
the scans. These optimizations reduce group formation time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Whenever an ongoing GO Neg has failed, due to interface init, the P2P
Device should cancel timeouts and issue wpas_p2p_group_formation_failed,
so the other peer detects faster group formation has failed.
Signed-off-by: Eduardo Abinader <eduardo.abinader@openbossa.org>
If a group interface is present and the command was issued on the group
interface, enable the token for that interface instead of creating a new
one.
Signed-off-by: Manish <manish.bansal@broadcom.com>
Add an option to specify a configuration file that can be used to hold
the P2P_DEVICE configuration parameters. If this option is not used, the
P2P_DEVICE configuration parameters will be read from interface
configuration file.
Note that it is advised to use this option in some cases such as:
If a P2P_DEVICE is supported by the driver, the wpa_supplicant creates a
dedicated P2P Device interface, where the configuration file used for
the main interface is used. As a consequence, if the configuration file
includes network definition etc., the wpa_supplicant will try to perform
station specific flows on the P2P Device interface which will fail.
If a P2P_DEVICE is supported by the driver and update_config is used,
the P2P Device configuration data will override the main interface
configuration data.
Signed-hostap: Ilan Peer <ilan.peer@intel.com>
wpa_config_write() is defined as a dummy function even if actual
operation to write the configuration file are commented out from the
build. This cleans up the code a bit and removed a compiler warning on
set-only variable.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
