If the TX success response races with the RX frame then the state
machine was simply move to P2P_SD_DURING_FIND to continue the operation.
However, this does not take into account broadcast queries where the
callback handler updates the peer's sd_pending_bcast_queries.
Fix this by exporting the callback and calling it directly. This is
fine, as the operation is cancelled immediately afterwards, ensuring
that the callback is not called a second time.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
If a GAS response is received for a pending SD query, process it even if
the TX status event for the query has not yet been received. It is
possible for the TX status and RX events to be reordered especially when
using UML time-travel, so this is needed to avoid race conditions to
make SD more robust.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When p2p->state == P2P_LISTEN_ONLY, the statement before it
'p2p->cfg->is_p2p_in_progress(p2p->cfg->cb_ctx)' will be true, too, so
this function will print a message "Operation in progress" and return;
the workaround to handle listen failure will be never reached.
I met such an error when the 'remain-on-channel' command failed, then
the function p2p_ext_listen_timeout() just printed 'Operation in
progress' again and again, and the listen operation was not started
anymore.
Fixes: 0f1034e388 ("P2P: Refrain from performing extended listen during P2P connection")
Signed-off-by: zhuhai <zhuhai.mail@163.com>
This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible for the start_listen() callback to be called to request
the driver to start a driver operation and stop_listen() called
immediately after that (e.g., due to a request to transmit a P2P Public
Action frame) before the driver has had time to start ROC and send an
event to notify of that. Such a sequence could result in
p2p->pending_listen_freq being left to a nonzero value without getting a
call to p2p_listen_cb() to clear it. This would stop an ongoing P2P
listen operation since no following p2p_listen() call would start the
listen due to the pending command being assumed to be in effect.
Fix this by detecting this particular sequence and clearing
p2p->pending_listen_freq.
This was found with the p2p_listen_and_offchannel_tx test case with the
new kernel scheduled and UML time-travel.
Signed-off-by: Jouni Malinen <j@w1.fi>
Verify that the operation succeeds before a debug print indicating that
it did. This was already done in most callers, so be more consistent and
do it here as well.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Check the ieee802_11_parse_elems() return code and do not proceed in
various cases if parsing failed. Previously, these cases would have been
allowed to continue by ignoring whatever might have followed in the IE
buffer after the first detected parsing failure. This is not really an
issue in practice, but it feels cleaner to explicitly stop when
receiving an invalid set of IEs.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add check to filter out 6 GHz frequencies from the local driver
frequency preference list when 6 GHz is not allowed for the P2P
connection. Earlier, 6 GHz frequency channels were included in the
preferred list if the p2p_6ghz_disable parameter was not set
irrespective of the allow_6ghz parameter.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Currently invitation request wait time is very long and not needed for
sending a single Action frame only. To not interfere with other parallel
channel activities, decrease the wait time to to 150 ms in case of an
active P2P GO on the system.
In addition, if a P2P GO tries to invite a client that doesn't respond,
it will attempt to invite again after 100 ms. This is too aggressive and
may result in missing beacon transmission and affecting GO activity on
its operating channel. Increase the timeout to 120 ms, to allow enough
time for beacon transmission.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
The dev pointer could potentially be NULL here in some P2PS cases, so
check it explicitly before dereferencing it when checking for 6 GHz
capability.
Fixes: b9e2826b9d ("P2P: Filter 6 GHz channels if peer doesn't support them")
Signed-off-by: Jouni Malinen <j@w1.fi>
It's necessary to maintain knowledge of the 6 GHz capability of the
peer. Since the Device Capability field migth change between frames
depending on the context in which they are used, loooking at the last
received message might not always provide accurate information.
Add supports_6ghz bool variable in struct p2p_device, initialize it to
false and set to true if the P2P_DEV_CAPAB_6GHZ_BAND_CAPABLE bit is set
to 1 in any P2P frame that includes the P2P Capability attribute. This
boolean would not be cleared to false at any point in time so that the
info doesn't disappear dynamically.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
P2P connections in the 6 GHz band should be limited to preferred
scanning channels since AP/GO discovery cannot depend on 2.4/5 GHz
discovery.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Previously, the driver could optionally (using QCA vendor command)
provide a preferred channel list to wpa_supplicant for channel selection
during the GO negotiation. Channel selection process can be more
efficient with the information of weights and flags of the preferred
channel list that can be provided by the driver. Use a weighted
preferred channel list provided by the driver for channel selection
during GO negotiation if such a list is available.
Signed-off-by: Sreeramya Soratkal <quic_ssramya@quicinc.com>
When 6 GHz channels are included in channel list of P2P Action frames
but some peer devices don't support the 6 GHz feature and cannot parse
P2P IE data correctly, P2P handshake will fail.
Remove 6 GHz channels from the P2P Action frames if the peer doesn't
support 6 GHz feature to avoid such failures.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Nul terminate the struct p2p_go_neg_results::passphrase explicitly to
keep static analyzers happier. This was already nul terminated in
practice due to the full array being cleared to zero on initialization,
but that was apparently not clear enough for some analyzers.
Signed-off-by: Jouni Malinen <j@w1.fi>
Copy channels from only valid operating classes in the source channel
list while preparing a non-6 GHz channel/op-classes list when the 6 GHz
band is not used for P2P GO negotiation.
Earlier, during preparation of P2P channels for GO negotiation, a union
of the GO channels and the P2P Client channels is used. While generating
the union in p2p_channels_union_inplace() as the first list itself has
P2P_MAX_REG_CLASSES number of entries, the operating classes from the
second list which are not in the first list were not getting considered.
Fix this by not setting the dst->reg_classes to too large a value.
Fixes: f7d4f1cbec ("P2P: Add a mechanism for allowing 6 GHz channels in channel lists")
Signed-off-by: Sreeramya Soratkal <quic_ssramya@quicinc.com>
Replaced the word "sanity" with the inclusive word "validity". The
comment in acs_survey_interference_factor() was referring a function
that does not exist, so remove it instead of trying rename the function.
Signed-off-by: Arowa Suliman <arowa@chromium.org>
Add an explicit check for msg->channel_list != NULL instead of depending
on msg->channel_list_len > 0 implying that. This is to silence invalid
static analyzer reports.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Align the p2p_buf_add_pref_channel_list() prototype and definition in
p2p_build.c and p2p_i.h. Use unsigned int over u32 as it is actully
called with an unsigned int parameter.
This removes compilation warning on platform where u32 != unsigned int.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
Commit 0b8889d8e5 ("P2P: Do not stop Listen state if it is on
correct channel") added a optimization to use Listen state's
remain-on-channel to send out GO Negotiation response frame quickly.
But in Listen state, if GO Negotiation request frame is received before
the remain-on-channel started event from the driver, the above
optimization is not triggered. This showed up in following manner in the
debug log:
p2p0: Starting radio work 'p2p-listen'@0xb4000070ae22d420 after 0.000114 second wait
nl80211: Remain-on-channel cookie 0x100 for freq=2412 MHz duration=204
P2P: Received GO Negotiation Request from 6e:fa:a7:86:e5:e5(freq=2412)
P2P: GO Negotiation with 6e:fa:a7:86:e5:e5
P2P: Stopping find
P2P: Clear timeout (state=WAIT_PEER_CONNECT)
P2P: State WAIT_PEER_CONNECT -> IDLE
nl80211: Cancel remain-on-channel with cookie 0x100
p2p0: Radio work 'p2p-listen'@0xb4000070ae22d420 done in 0.074348 seconds
p2p0: radio_work_free('p2p-listen'@0xb4000070ae22d420): num_active_works --> 0
P2P: State IDLE -> GO_NEG
P2P: Sending GO Negotiation Response
Off-channel: Send action frame: freq=2412 dst=6e:fa:a7:86:e5:e5 src=da:3c:83:7d:70:2b bssid=da:3c:83:7d:70:2b len=196
nl80211: Remain-on-channel event (cancel=0 freq=2412 channel_type=0 duration=400 cookie=0x100 (match))
nl80211: Remain-on-channel event (cancel=1 freq=2412 channel_type=0 duration=0 cookie=0x100 (match))
P2P: GO Negotiation Response (failure) TX callback: success=0
Fix this by adding p2p->pending_listen_freq == freq condition for the
optimization so that the case where the remain-on-channel command has
already been issued to the driver, but the start event has not yet been
received, is covered as well.
Fixes: 0b8889d8e5 ("P2P: Do not stop Listen state if it is on correct channel")
Signed-off-by: Hu Wang <huw@codeaurora.org>
Previously, 6 GHz channels were disabled for P2P operations. Use the new
allow_6ghz parameter with P2P_CONNECT, P2P_GROUP_ADD, and P2P_INVITE
commands for P2P connection on the 6 GHz channels when Wi-Fi Display is
enabled on both the devices.
However, the p2p_6ghz_disable parameter in the configuration takes a
higher precedence.
Indicate P2P 6 GHz band capable information in Device Capability Bitmap
of P2P Capability attribute to indicate the P2P Device is capable of P2P
operation in the 6 GHz band.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Introduce a new allow_6ghz parameter to allow 6 GHz channels to be
filtered out when copying channel lists.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Previously, the 6 GHz channels were disabled for P2P operations.
Introduce a new include_6ghz parameter for the P2P_FIND command to
configure P2P discovery on the 6 GHz channels.
However, the p2p_6ghz_disable parameter in the configuration takes a
higher priority. If the p2p_6ghz_disable parameter is not set in the
configuration, include_6ghz parameter can be used to enable or disable
the discovery operation in the 6 GHz channels for the P2P_FIND command.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
P2P operation on the 6 GHz band is supported in the WFD use case.
Introduce helper functions to check for Wi-Fi Display capability of
the local device and a peer device.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Introduce P2P 6 GHz band capable information in Device Capability
Bitmap of P2P Capability sub-attribute.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
If listen work never started, pending_listen_freq might be left
uncleared, preventing the subsequent listen to start. This could happen
in p2p_timeout_wait_peer_idle() after the commit 13256b8cf ("P2P: Stop
old listen radio work before go to WAIT_PEER_IDLE state") added a
stop_listen() call there.
Fixes: 13256b8cf3 ("P2P: Stop old listen radio work before go to WAIT_PEER_IDLE state")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
p2p_add_device() may remove the oldest entry if there is no room in the
peer table for a new peer. This would result in any pointer to that
removed entry becoming stale. A corner case with an invalid PD Request
frame could result in such a case ending up using (read+write) freed
memory. This could only by triggered when the peer table has reached its
maximum size and the PD Request frame is received from the P2P Device
Address of the oldest remaining entry and the frame has incorrect P2P
Device Address in the payload.
Fix this by fetching the dev pointer again after having called
p2p_add_device() so that the stale pointer cannot be used.
Fixes: 17bef1e97a ("P2P: Add peer entry based on Provision Discovery Request")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is mainly to help with fuzz testing that could generate overly long
test data that would not be possible in real use cases due to MMPDU size
limits. The implementation for storing vendor IEs with such
unrealisticly long IE buffers can result in huge number of memory
reallozations and analyzing those can be very heavy.
While the maximum length of the fuzzing test input could be limited, it
seems nicer to limit this IE storage limit instead to avoid timeouts
from fuzz test runs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Parsing and copying of WPS secondary device types list was verifying
that the contents is not too long for the internal maximum in the case
of WPS messages, but similar validation was missing from the case of P2P
group information which encodes this information in a different
attribute. This could result in writing beyond the memory area assigned
for these entries and corrupting memory within an instance of struct
p2p_device. This could result in invalid operations and unexpected
behavior when trying to free pointers from that corrupted memory.
Credit to OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27269
Fixes: e57ae6e19e ("P2P: Keep track of secondary device types for peers")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When an external scan is in progress on the same radio, delay the P2P
search operation based on configuration parameter p2p_search_delay. The
"search_delay" configuration done through p2p_find always takes
precedence over this delay value set due to an external scan trigger.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously, the configuration to disable the 6 GHz band remained local
to the P2P interface. With this there is a possibility of 6 GHz channels
being included in the channel list when the channel list needs to be
updated if the state changes on one of the interfaces.
Include the configuration to disable the 6 GHz band for P2P as a global
configuration value to prevent the inclusion of 6 GHz channels in the
channel list for P2P when the channel list needs to be updated during
the state change in one of the interfaces.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
P2P goes to Listen state while waiting for the peer to become ready for
GO Negotiation. If old listen radio work has not been completed, P2P
fails to go to listen state. This could happen in cases where P2P Action
frame transmission reused ongoing p2p-listen radio work.
p2p0: Add radio work 'p2p-listen'@0x
P2P-FIND-STOPPED
p2p0: Starting radio work 'p2p-listen'@0x after 0.010644 second wait
P2P: Use ongoing radio work for Action frame TX
P2P: Use ongoing radio work for Action frame TX
P2P: State CONNECT -> CONNECT
P2P: State CONNECT -> WAIT_PEER_IDLE
P2P: State WAIT_PEER_IDLE -> WAIT_PEER_CONNECT
P2P: Reject start_listen since p2p_listen_work already exists
P2P: Failed to start listen mode
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
We don't really need to duplicate more of this, so just
move the lib.rules include to the end and do more of the
stuff that's common anyway there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Derive the library name from the directory name, and let each
library Makefile only declare the objects that are needed.
This reduces duplicate code for the ar call. While at it, also
pretty-print that call.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is something I hadn't previously done, but there are
cases where it's needed, e.g., building 'wlantest' and then
one of the tests/fuzzing/*/ projects, they use a different
configuration (fuzzing vs. not fuzzing).
Perhaps more importantly, this gets rid of the last thing
that was dumped into the source directories, apart from
the binaries themselves.
Note that due to the use of thin archives, this required
building with absolute paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of building in the source tree, put most object
files into the build/ folder at the root, and put each
thing that's being built into a separate folder.
This then allows us to build hostapd and wpa_supplicant
(or other combinations) without "make clean" inbetween.
For the tests keep the objects in place for now (and to
do that, add the build rule) so that we don't have to
rewrite all of that with $(call BUILDOBJS,...) which is
just noise there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some of the operating classes added in the 6 GHz band have a larger
number of channels included in them (e.g., operating class 131 has 59
channels). Increase the maximum number of channels per operating class
so that all channels will get populated.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows a P2P connection over P802.11ay EDMG channels to achieve the
highest link speed that the standard allows for channel bonding (CB) up
to CB4.
Let each P2P peer add its EDMG channels to the Supported Channels IE
advertised in P2P GO negotiation. Give EDMG channels priority when peers
negotiate for operating channel.
User may add 'edmg' parameter to p2p_connect, p2p_add_group, and
p2p_invite commands to prefer an EDMG channel for the P2P link. User may
also set p2p_go_edmg=1 in wpa_supplicant configuration file to prefer
EDMG.
When EDMG is used, P2P will try to find the highest channel bonding
supported channel that matches the frequency parameter, if the devices
do not support EDMG, the P2P connection will use a legacy (1-6) 60 GHz
channel.
Signed-off-by: Ahmad Masri <amasri@codeaurora.org>
Commit 947b5a1532 ("P2P: Stop listen state if Action frame TX is
needed on another channel") added an optimization for P2P response
transmission in certain concurrent operation cases. However, it did not
take into account possibility of the driver not being in listen
state (p2p->drv_in_listen == 0) and could end up getting stuck with the
P2P state machine in a manner that made the device not listen for
following messages. This showed up in following manner in the debug log:
P2P: Starting short listen state (state=SEARCH)
P2P: Driver ended Listen state (freq=2437)
process received frame and send a response
P2P: Stop listen on 0 MHz to allow a frame to be sent immediately on 2437 MHz
P2P: Clear timeout (state=SEARCH)
--> state machine stuck
Fix this by adding drv_in_listen > 0 condition for the optimization to
stop the listen operation in send_action() resulting in scheduled TX.
Fixes: 947b5a1532 ("P2P: Stop listen state if Action frame TX is needed on another channel")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If there are no post-provision discovery operations, we should continue
in find mode to avoid getting the p2p_find operation stopped (stuck in
SEARCH state) unexpectedly.
Signed-off-by: Jimmy Chen <jimmycmchen@google.com>
'sizeof' was not used with os_memmove() for an integer array. This lead
to an issue with part of the preferred channel list not being used.
Fixes: 79329ae0aa ("P2P: Verify local driver preferred frequencies for P2P use cases")
Signed-off-by: Daichi Ueura <daichi.ueura@sony.com>
With radio work design, send Action frame request will be queued and
wait for p2p-scan to finish, so there is no need to delay send_action.
This change revisits the logic (added before the radio work framework)
in below commits:
3f9285f P2P: Delay send_action call if p2p_scan is in progress
f44ae20 P2P: Drop pending TX frame on new p2p_connect
9d562b7 P2P: Add p2p_unauthorize command
63a965c P2P: Fix after_scan_tx processing during ongoing operations
9a58e52 P2PS: Callback to create pending group after sending PD Response
3433721 P2P: Continue p2p_find after sending non-success Invitation Response
Signed-off-by: Hu Wang <huw@codeaurora.org>
The Multi-AP specification adds a new subelement to the WFA extension
element in the WPS exchange. Add an additional parameter to
wps_build_wfa_ext() to add this subelement. The subelement is only added
if the parameter is nonzero. Note that we don't reuse the existing
MULTI_AP_SUB_ELEM_TYPE definition here, but rather define a new
WFA_ELEM_MULTI_AP, to make sure the enum of WFA subelement types for WPS
vendor extension remains complete.
For now, all callers set the multi_ap_subelem parameter to 0.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This speeds up P2P responses to frames received on an operating channel
in case there is an ongoing P2P listen operation on another channel.
This is applicable to drivers that support multiple channels in
concurrently.
This addresses an issue showing up in the
p2ps_channel_active_go_and_station_different_mcc test case where the
Provision Discovery Request frame can be received on the operating
channel of a group instead of the Listen channel. The response was
delayed until the listen operation timed out and this took too long time
for the peer to receive the response.
Signed-off-by: Jouni Malinen <j@w1.fi>
p2p->find_start timer was updated on each p2p_find call irrespective of
p2p_find being successful/failed/rejected. For cases where p2p_find was
in progress/pending, another call to p2p_find would be rejected but
p2p->find_start timer would still be updated.
p2p->find_start is maintained in wpa_supplicant to reject the kernel
scan entries before the p2p->find_start time. In above scenario, some of
the scan entries could be discarded even if the Probe Respons frame(s)
were received during the last scan/p2p_find.
This commit changes this to update the p2p->find_start timer only when
call to p2p_find is successful, i.e., a new scan is actually started.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The avoid channels are notified through
QCA_NL80211_VENDOR_SUBCMD_AVOID_FREQUENCY allow minimal traffic, so
enhance the P2P behavior accordingly by considering these avoid
frequencies for P2P discovery/negotiation as long as they are not in
disallowed frequencies list.
Additionally, do not return failure when none of social channels are
available as operation channel, rather, mark the op_channel/op_reg_class
to 0 as this would anyway get selected during the group formation in
p2p_prepare_channel.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
