This is needed for P2P2 pairing using PASN. The actual processing will
be covered in separate commits.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add a function to fragment P2P/P2P2 IE exceeding 255 bytes in size and
use this for P2P IE in GO Negotiation frames in preparation for P2P2.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Support generation of the GO Negotiation frames with contents that is
needed for P2P2 wrapped case.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
It is clearer to use enum p2p_status_code instead of u8 when processing
and passing the P2P Status Code to other components.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add wrapper functions to process and prepare a response for GO
Negotiation and Invitation frames. Send the response Action frames in
handle_ functions. This is in preparation for encapsulating these
messages within PASN Authentication frames for P2P2.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add support for P2P2 bootstrapping with comeback mechanism using
Provision Discovery frames. Extend the control interface command
P2P_CONNECT to allow P2P2 bootstrapping handshake.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Parse the P2P IEs in functions that handle provision discovery request
and response. Process the frames based on the IEs received in the PD
frames. This makes it easier to extend PD for P2P2 cases.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Process the Element Container attribute from NAN SDF frames and check if
P2P attributes are present. Add a P2P peer device entry if the NAN SDF
frame has matching service and P2P capabilities.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add DIRA attribute in P2P2 IE of NAN Subscribe and Publish frames
to enable support for device identity of paired peers.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add PCEA and PBMA attribute in P2P2 IE of NAN Subscribe and Publish frames
to include the P2P2 capabilities and bootstrapping methods.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Extend the NAN Subscribe and Publish methods to allow p2p=1 to be
specified to include P2P attributes in a P2P IE to be added into the NAN
Element Container attribute. In addition, use the P2P Device Address for
the NAN SDFs for the P2P cases.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
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>
