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>
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>
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>
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>
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>
Some drivers may accept the remain-on-channel command, but instead of
indicating start event for remain-on-channel, just indicate that the
operation has been canceled immediately. This listen cancel from the
WAIT_PEER_CONNECT state ended up in discontinuation of further
WAIT_PEER_IDLE/WAIT_PEER_CONNECT state transitions. Hence, delay the
subsequent IDLE state by 100 ms.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If a P2P_FIND command is issued for running the initial full scan and
the attempt to start that full scan fails, the previous behavior was to
wait for the ongoing scan to complete and then continue p2p_find scan
iterations. However, this continued with the social channels scan
instead of the initial full scan. This could end up missing the full
scan completely.
Fix this by marking the full scan pending if the new scan cannot be
started immediately. Then start the initial full scan after the ongoing
scan completes before moving to social channel only scan iterations.
This applies both for the P2P_FIND_START_WITH_FULL (no specific
frequency set) and P2P_FIND_PROGRESSIVE cases since both of them start
with a single full scan round.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes the "P2P_FIND freq=<MHz>" operation more robust by continuing
to include the specified frequency in the consecutive scan rounds
instead of including it only once in the first scan. In other words, the
first scan is only for the specified frequency just like the previous
behavior, but the following scans include all the social channels and
the specified frequency instead of just the previously used social
channels.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This leads to cleaner code overall, and also reduces the size
of the hostapd and wpa_supplicant binaries (in hwsim test build
on x86_64) by about 2.5 and 3.5KiB respectively.
The mechanical conversions all over the code were done with
the following spatch:
@@
expression SIZE, SRC;
expression a;
@@
-a = os_malloc(SIZE);
+a = os_memdup(SRC, SIZE);
<...
if (!a) {...}
...>
-os_memcpy(a, SRC, SIZE);
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This new P2P_SET parameter uses <op_class>:<channel> format and is used
mainly for testing purposes to allow overriding the value of the GO
Negotiation Response frame Operating Channel attribute.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The address of msg.device_name array is obviously always true, and some
compilers even warn about it.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
This is to handle the case when peer changes device name and same needs
to be updated to upper layers by P2P-DEVICE-FOUND event. It is similar
to the case when a peer changes wfd_subelems and P2P-DEVICE-FOUND event
goes to upper layers.
Signed-off-by: Mayank Haarit <mayank.h@samsung.com>
Signed-off-by: Avichal Agarwal <avichal.a@samsung.com>
When a peer device stops sending wfd_subelems, wpa_supplicant should
remove dev->info.wfd_subelems from peer's properties. Previously,
wpa_supplicant left the previously learned dev->info.wfd_subelems in
place whenever the new message did not include wfd_subelems.
In addition to fixing the clearing of the old wfd_subelems, this
resolves another issue. As "wfd_changed" variable becomes true even when
peer stops sending wfd_subelems and dev->info.wfd_subelems has an old
value, a new P2P-DEVICE-FOUND event notification was sent again and
again to upper layers whenever a new discovery response was received
from the peer that previously advertised WFD subelements.
Signed-off-by: Mayank Haarit <mayank.h@samsung.com>
Previously, this flag was cleared only in case of failed GO Negotiation.
That could leave the flag set for a peer and if a new group formation
was performed with the same peer before the entry expired, there was
increased risk of getting stuck in a state where neither peer replied to
a GO Negotiation Request frame if a GO Negotiation Response frame with
Status 1 was dropped.
The error sequence could happen in the go_neg_with_bss_connected test
case when timing was suitable to make the second GO negotiation drop a
pending TX Action frame if the GO Negotiation Response with Status 1 was
scheduled for transmission during a P2P scan and P2P_CONNECT was issued
before that scan got aborted.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Receiving a provision discovery request for an ASP service that
has auto accept set to false should result in a provision discovery
response with the status field set to "currently unavailable".
Having stale P2PS provision data, results in sending a response with
the status set to success because it is mistakenly referred to as the
follow-on provision discovery request.
Fix that by clearing stale P2PS provision data in the following cases:
1. When provision discovery is complete
2. When ASP services are flushed (in which case old ASP provisioning
is no longer valid).
Signed-off-by: Avrahams Stern <avraham.stern@intel.com>
Otherwise, if a P2PS provision is incomplete before the flush, it can
cause incorrect provision responses to be sent out.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
If a peer stops sending adv_service_instance, we should clear the
existing dev->info.p2ps_instance.
This commit fixes the following scenario:
When peer device stops sending adv_service_instance, wpa_supplicant did
not remove old dev->info.p2ps_instance from device's property. This
variable should be updated as per peer behavior and should be cleared
when peer stops sending this information.
Signed-off-by: Nishant Chaprana <n.chaprana@samsung.com>
Remove the unnecessary os_free() call from p2p_deinit() since
p2p_flush() called just above this takes care of freeing
p2p->after_scan_tx and the second call here ends up being no-op
os_free(NULL) in practice.
Signed-off-by: Mayank Haarit <mayank.h@samsung.com>
This allows P2P Listen to be offloaded to device to enhance power
saving.
To start P2P listen offload, from wpa_cli interface, issue the command:
p2p_lo_start <freq> <period> <interval> <count>
To stop P2P listen offload, issue the command:
p2p_lo_stop
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This was previously handled for the case where the non-success
Invitation Response frame was sent out during the Listen phase. However,
in the case the Action frame TX ended up getting scheduled when the
Search phase scan had already started (e.g., due to the driver reporting
Invitation Request RX late enough for the Listen-to-Search transition
having already started), the postponed Action frame TX status processing
did not cover the specific case of non-success Invitation Response. This
could result in the p2p_find operation getting stopped (stuck in SEARCH
state) unexpectedly.
Fix this by calling p2p_check_after_scan_tx_continuation() from
Invitation Response TX callback handler if the invitation was rejected.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
In case a Probe Request frame is received from a known peer P2P Device,
update the listen channel based on the P2P attributes in the Probe
Request frame. This can be useful for cases where the peer P2P Device
changed its listen channel, and the local P2P device is about to start a
GO Negotiation or invitation signaling with the peer.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When building P2P IE for Probe Request frames in P2P scan, add the
device information attribute if the 60 GHz band is included in the scan,
since this is required by the P2P specification.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
This makes it easier to debug issues with old scan results being ignored
during P2P_FIND. A single rx_time would have been fine with
os_gettime(), but with os_get_reltime(), both rx_time and find_start
values are needed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previous behavior of bursting out all retry attempts of an SD Query
frame during a single search/listen iteration does not look very helpful
in the case where the peer does not ACK the query frame. Since the peer
was found in the search, but is not ACKing frames anymore, it is likely
that it left its listen state and we might as well do something more
useful to burst out a significant number of frames in hopes of seeing
the peer.
Modify the SD Query design during P2P Search to send out only a single
attempt (with likely multiple link-layer retries, if needed) per
search/listen iteration to each peer that has pending SD queries. Once
no more peers with pending queries remain, force another Listen and
Search phase to go through before continuing with the pending SD
queries.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the p2p->pending_listen_freq to be left indicating
that there is a pending ROC for a listen operation if a P2P_FIND command
was timed to arrive suitably between a previous Listen operation issuing
a ROC request and the kernel code starting that request. This could
result in the P2P state machine getting stuck unable to continue the
find ("P2P: p2p_listen command pending already").
Fix this by clearing p2p->pending_listen_freq when starting P2P_FIND
command execution.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new optional group_ssid=<hexdump> argument in the P2PS-PROV-DONE
event can be used to help in identifying the exact group if there have
been multiple groups with the same P2P Interface Address in short period
of time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
P2P device discovery can add peer entries based on a message directly
from a peer and from a Probe Response frame from a GO for all the P2P
Clients in the group. The former case for filtering out control
characters from the device name while the latter was not. Make this
consistent and filter both cases in the same way to avoid confusing
external programs using the device name of a P2P peer.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
On successful P2P PD, report the chosen frequency in case the local
device is going to be the P2P GO, so in can later be used to instantiate
the new P2P GO, etc.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add operating channel selection and channel list processing similar to
that done when building GO Negotiation Request, i.e., consider the
currently used channels, configured channels, etc.
P2PS introduces a flow where a responder needs to provide channel data
without being previously aware of the current constraints, i.e., the
channels currently in use by other interfaces. To handle this, extend
the get_group_capability() callback to also handle channel selection
aspects of group capabilities.
In case there is an active P2P GO that is going to be used for the P2PS
PD, force its current operating frequency in the PD attributes.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When a follow-on PD request is received, peer should not send a
follow-on PD response except the case when the PD request status value
is 12 (Success: accepted by user). Previously, the wpa_supplicant
implementation behaved differently sending the follow-on PD Response on
any follow-on PD Request.
Fix the issue by adding the following changes:
1. Don't send PD Response if the follow-on PD Request status is
different than 12 (seeker side).
2. Don't wait for the follow-on PD Response if the follow-on PD
Request was sent with the status different than 12 (advertiser
side).
3. If the follow-on PD Request was sent with the status different
than 12 use the follow-on PD Request ACK as PD completion event
(advertiser side).
4. Notify ASP about the PD completion by sending P2PS-PROV-DONE with
the PD Request status (advertiser side).
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
It is expected that p2p_flush() should stop any ongoing p2p operation.
However, this was not the case with extended listen which was not
cancelled on p2p_flush() flows. Fix this, by cancelling the extended
listen in p2p_flush().
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
If the driver supports the preferred frequency list extension, use this
information from the driver when no explicitly configured preference
list (p2p_pref_chan) is present for P2P operating channel selection.
This commit adds this for GO Negotiation and Invitation use cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add Coordination Transport Protocol parameter to P2P_SERVICE_ADD
asp command.
Extend p2ps_advertisement structure to contain CPT priorities
and a supported CPT bitmask.
The format of the new parameter:
cpt=<cpt>[:<cpt>]
where <cpt> is a name of the Coordination Protocol Transport.
This implementation supports two CPT names: UDP and MAC.
The order of specified CPTs defines their priorities where
the first one has the highest priority.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Previously, one timeout per process (by default every 30 seconds) was
used P2P peer expiration and another per-interface timeout (every 10
seconds) was used to expire BSS entries. Merge these to a single
per-process timeout that triggers every 10 seconds to minimize number of
process wakeups due to periodic operations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the previously set SSID to remain in place between
test cases (e.g., in sequence "p2ps_connect_adv_go_persistent
p2p_set_ssid_postfix") and the P2P SSID postfix not getting used
properly. Make this less likely to occur by clearing the old SSID in
p2p_flush().
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
