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>
It looks like discovery_dev_id test case can still fail and based on the
previously added debug prints, this is happening since the P2P module
believes it is not in Listen state even when a P2P_LISTEN was issued.
p2p_listen_cb() did not get called on remain-on-channel event for some
reason, so lets add more debug to find out why this can happen.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
While testing rfkill blocking of a scanning interface, it
was seen that the ongoing scan never completes. This happens
since EVENT_SCAN_RESULTS is discarded on a disabled interface.
Fix this and also other possible radio work completion issues
by removing all the radio works (including started) of the
disabled interface.
To be able to remove already started radio works, make their
callbacks be reentrant with deinit flag (when the work
is started), so each radio work should be able to handle
its own termination.
Signed-hostap: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Initialize flag variable explicitly to avoid [-Wmaybeuninitialized]
compiler warning in wpas_p2p_verify_channel().
Signed-hostap: Max Stepanov <Max.Stepanov@intel.com>
P2P persistent connection may fail due to 802.11d channel change event
invalidating support of the operating frequency sent in the invitation
request, before receiving the invitation response. If the operating
frequency is invalid at the time the invitation response is processed
and there is no forced frequency provided by user, allow frequency
re-selection.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
os_free has wfd_dev_info_hex as an argument which is defined within
CONFIG_NO_STDOUT_DEBUG
Signed-hostap: Prashanth Kumar <prashanthkumar.kr@globaledgesoft.com>
This can be used to force an operating channel for P2P group formation
triggered by NFC operations.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
These optional attributes, if present, can be used to speed up the
initial connection by using a single channel scan.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This adds a new P2P Invitation mechanism to invite a P2P Device with an
NFC Tag to an already operating group when the GO with NFC Device reads
the NFC Tag. The P2P Device with the NFC Tag will then accept invitation
and connect to the group automatically using its OOB Device Password.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When "P2P_SET nfc_tag 1" is used to enable the own NFC Tag for P2P, also
enable it for any running GO interface.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
P2P Group ID can optionally be included in the connection handover
messages when acting as a P2P Client in a group. Add this information
and show it in the P2P-NFC-PEER-CLIENT event message.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When the NFC connection handover message received from a peer indicates
that the peer is operating as a GO on a specific channel, use that
information to avoid having to go through full scan. In addition, skip
the separate join-a-group scan since we already know the operating
channel, GO P2P Device Address, and SSID.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The DH public and private key needs to be copied for the separate group
interface if that is used for a P2P group.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Instead of automatically triggering a connection, provide an indication
of one of the devices being a P2P client to upper layers to allow user
to determine what to do next.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Send a P2P-NFC-BOTH-GO event to upper layers to determine what to
do in case both devices going through NFC connection handover are
already operating as a GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This new mechanism allows P2P Client to request an IPv4 address from the
GO as part of the 4-way handshake to avoid use of DHCP exchange after
4-way handshake. If the new mechanism is used, the assigned IP address
is shown in the P2P-GROUP-STARTED event on the client side with
following new parameters: ip_addr, ip_mask, go_ip_addr. The assigned IP
address is included in the AP-STA-CONNECTED event on the GO side as a
new ip_addr parameter. The IP address is valid for the duration of the
association.
The IP address pool for this new mechanism is configured as global
wpa_supplicant configuration file parameters ip_addr_go, ip_addr_mask,
ip_addr_star, ip_addr_end. For example:
ip_addr_go=192.168.42.1
ip_addr_mask=255.255.255.0
ip_addr_start=192.168.42.2
ip_addr_end=192.168.42.100
DHCP mechanism is expected to be enabled at the same time to support P2P
Devices that do not use the new mechanism. The easiest way of managing
the IP addresses is by splitting the IP address range into two parts and
assign a separate range for wpa_supplicant and DHCP server.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The device with the NFC Tag can be configured to enable NFC to be used
with "P2P_SET nfc_tag 1" and "P2P_LISTEN" commands to allow static
handover to be used.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
