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>
drv->in_listen should be cleared whenever the state timeout is cleared,
if they were set together. If the flag is not cleared, the
p2p_listen_end() called during cancel-remain-on-channel will not restart
the search, relying on the state timeout function to do it. Use the
p2p_stop_listen_for_freq() function to clear the listen state properly.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@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>
Ignore group members for which there is no supported channels
information when calculating common group frequencies.
Signed-off-by: Ilan Peer <ilan.peer@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>
Add P2PS config flag only when config_methods are set. This restores the
pre-P2PS behavioer for the cases where Display or Keypad config method
is specified for a peer (i.e., do not add the new P2PS method in that
case).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This allows local GO to fetch the P2P Interface Address of a P2P Client
in the group based on the P2P Device Address for the client. This
command should be sent only on a group interface (the same peer may be
in multiple concurrent groups).
Usage:
P2P_GROUP_MEMBER <P2P Device Address>
Output:
<P2P Interface Address>
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.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>
This group capability bit was previously added unconditionally which
could result in the P2P Client assuming the functionality is available
even though the GO would always reject the request (not reply to it with
an assigned IP address) during the 4-way handshake.
Fix this by advertising the capability only if the GO configuration
allow IP address assignment to be completed.
Signed-off-by: Jouni Malinen <j@w1.fi>
In the 60 GHz band, service discovery management frames are sent over
the control PHY and have a smaller maximum frame size (IEEE Std
802.11ad-2012, 21.4.3.2). Fix the code to use sufficiently small
fragment size when operating in the 60 GHz band.
The 60 GHz fragment size (928) is derived from the maximum frame size
for control PHY (1023) and subtracting 48 bytes of header size, and some
spare so we do not reach frames with the absolute maximum size.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Update the peer WFD IE information based on WFD elements received in
Provision Discovery Response and GO Negotiation Response frames.
Signed-off-by: Avichal Agarwal <avichal.a@samsung.com>
Signed-off-by: Kyeong-Chae Lim <kcya.lim@samsung.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>
Setting a long off channel wait time for P2P Action frames when
we know we are already on the right channel may cause a delay in
sending the Action frame (because the driver may not be able to
satisfy the request for long wait time until previous off channel
requests are over). This may be crucial for P2P response frames
that must be sent within 100 milliseconds of receiving the request.
Fix this by adjusting P2P Action frame wait times as follows:
1. For GO Negotiation Response frame, shorten the wait time to 100 ms.
This is reasonable because the peer has just sent us the GO
Negotiation Request frame, so it is known to be on the right
channel and is probably ready to send us the GO Negotiation
Confirmation frame without delay.
2. For GO Negotiation Confirmation, P2P Invitation Response, and
Provision Discovery Response frames, there is no need for wait
time at all as this is the last frame in the exchange. So set
the wait time to 50 ms to ensure there is enough time to send the
frame.
Signed-off-by: Avraham Stern <avraham.stern@intel.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>
The new max_oper_chwidth and freq2 arguments to P2P_CONNECT, P2P_INVITE,
and P2P_GROUP_ADD control interface commands can be used to request
larger VHT operating channel bandwidth to be used than the previously
used maximum 80 MHz.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds definitions for the global operating classes 129 and 130 for
VHT 80+80 MHz and 160 MHz use cases.
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>
This improves robustness of GO Negotiation in special cases where GO
Negotiation Request frames from the peer may end up getting delivered
multiple times, e.g., due to interference and retransmitted frames not
getting properly filtered out in duplicate detection (which is something
that number of drivers do not implement for pre-associated state).
If we have already replied with GO Negotiation Response frame with
Status 1 (not yet ready), do not reply to another GO Negotiation Request
frame from the peer if we have already received authorization from the
user (P2P_CONNECT command) for group formation and have sent out our GO
Negotiation Request frame. This avoids a possible sequence where two
independent GO Negotiation instances could go through in parallel if the
MAC address based rule on avoiding duplicate negotiations is not able to
prevent the case. This can allow GO Negotiation to complete successfully
whereas the previous behavior would have likely resulted in a failure
with neither device sending a GO Negotiation Confirm frame.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Don't add unnecessary P2PS follow-on PD Request attributes when
the request status is not P2P_SC_SUCCESS_DEFERRED.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
In P2PS PD Request processing in some error case scenarios, such as
verification of the WPS config method, the flow aborts before saving
mandatory P2PS PD Request attributes. This in turn causes the control
interface notification events to be sent with invalid parameters.
Fix this by changing the order of verification and processing steps of
the PD Request message handling.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
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>
In case the P2PS PD Response includes the P2P Channel List attribute,
update the peer device supported channels and verify that the local
device has common channels with the peer (only a sanity check).
If the Operating Channel attribute is included in the response, check
that it is included in the intersection and store it as the peer's
operating frequency (so it could later be used in the join flow, etc.).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
In case the P2PS PD Request includes the P2P Channel List attribute,
update the peer device supported channels and check if we have common
channels with the peer that can be used for the connection establishment
based on the connection capabilities:
1. In case of P2PS PD Request with no common channels, defer
the flow unless auto accept equals true and the connection
capabilities equals NEW (in which case the channels would be
negotiated in the GO Negotiation).
2. In case of Follow up P2PS PD Request with no common channels,
reject the request unless the connection capability is NEW.
In addition, in case of a successful P2PS PD, save the device
operating frequency (so it can be later used for join flow, 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>
If a Provision Discovery Request is received for an unknown peer, a new
device entry is being added, but the flow continues without updating the
local p2p_device pointer, requiring to check the pointer value before
every access.
1. Change this, so once a device is added, the flow updates the local
p2p_device pointer and avoids the checks later in the flow.
2. If the device is not known even after adding it, skip the processing,
send the PD Response, and return.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
It is possible that p2p_build_prov_disc_resp() is called with a NULL
device entry, which might be dereferenced when calling
p2p->cfg->get_persistent_group() for the P2PS with persistent group
case. Fix this by checking the device pointer before accessing it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Validate that all the required attributes appear in a P2PS PD Request,
and in addition, in the case of follow-on PD Request, check that the
given values match those of the original PD Request.
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>
When using P2P invitation to re-invoke a persistent P2P group without
specifying the operating channel, query the driver for the preferred
frequency list, and use it to select the operating channel of the group.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use NULL to indicate if the address is not available instead of fixed
00:00:00:00:00:00. wpas_p2ps_prov_complete() already had code for
converting NULL to that all zeros address for event messages.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Change P2PS P2P-PROV-SHOW-PIN/P2P-PROV-ENTER-PIN event notifications
on PD Request/Response handling to meet required P2PS behavior.
The new implemented scheme:
1. For a legacy P2P provision discovery the event behavior remains
without changes
2. P2PS PD, advertiser method: DISPLAY, autoaccept: TRUE:
Advertiser: SHOW-PIN on PD request replied with a status SUCCESS
Seeker: ENTER-PIN on PD response received with a status SUCCESS
3. P2PS PD, advertiser method: DISPLAY, autoaccept: FALSE:
Advertiser: SHOW-PIN on PD request replied with a status
INFO_CURRENTLY_UNAVAILABLE
Seeker: ENTER-PIN on Follow-on PD request with a status
SUCCESS_DEFERRED
4. P2PS PD, advertiser method: KEYPAD, autoaccept: TRUE/FALSE:
Advertiser: ENTER-PIN on PD request replied with a status
INFO_CURRENTLY_UNAVAILABLE
Seeker: SHOW-PIN on PD response received with a status
INFO_CURRENTLY_UNAVAILABLE
This change in behavior breaks the existing test cases
p2ps_connect_keypad_method_nonautoaccept and
p2ps_connect_display_method_nonautoaccept. Those will be fixed in a
followup commit.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Add a function to compute the group common frequencies, and
use it to update the group_common_frequencies as part of the
channel switch flows.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add ieee80211_freq_to_channel_ext() conversion function into
ieee802_11_common.c. This function converts freq to channel and
additionally computes operating class, based on provided HT and VHT
parameters.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
It looks like the compiler version used in Android 5.0 warns about
potentially uninitialized oper_freq variable in these debug messages.
That is not really valid since this code path can be reached only if
found != 0 and in such a case, oper_freq is set. Anyway, it seems better
to avoid compiler warnings, so add an unnecessary initialization for
oper_freq for now.
Signed-off-by: Jouni Malinen <j@w1.fi>
When processing a GO Negotiation Request and Response, if local driver
supports the preferred channel list extension, then:
- Check if peer's preference for operating channel is already included
in our preferred channel list and if so, take the oper_channel as is.
- If peer's preference for operating channel is not in local device's
preferred channel list and peer device has provided its preferred
frequency list in the GO Negotiation Request/Response, then find a
channel that is common for both preferred channel lists and use it
for oper_channel.
- If peer's preference for operating channel is not in local device's
preferred channel list and peer device doesn't use preferred channel
list extension, i.e., no preferred channel list in GO Negotiation
Request/Response, then look for a channel that is common for local
device's preferred channel list and peer's list of supported channels
and use it for oper_channel.
- In case no common channel is found, use the peer's preference for
oper_channel as is.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds a callback function that can be used from the P2P module to
request the current preferred list of operating channels from the
driver.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add an extra condition to omit operating channel preference when
building GO Negotiation Response. If the local device supports the
preferred frequency list extension, then when sending a GO Negotiation
Response frame, advertise the preferred operating channel unless local
device is assuming the P2P Client role and has an empty preferred
frequency list, in which case local device can omit its preference for
the operating channel.
This change helps make use of the preferred frequency list and the
calculated best channel for both negotiating parties of the P2P
connection.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When sending a GO Negotiation Request, advertise the preferred frequency
list in a new vendor specific IE. This can be used to extend the
standard P2P behavior where a single preferred channel can be advertised
by allowing a priority list of channels to be indicated.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.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>
Report the feature capability on P2PS-PROV-START and P2PS-PROV-DONE
ctrl-iface events. A feature capability value is specified as
'feature_cap=<hex>' event parameter, where <val> is a hexadecimal
string of feature capability bytes in a PD Response frame.
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>
On PD Request/follow-on PD Request preparation set a feature capability
CPT value of PD context.
On PD Request processing use a request CPT and service advertisement
CPT priority list to select a feature capability CPT of PD Response.
On follow-on PD Request processing use a request CPT and a CPT priority
list in PD context to select a CPT value of follow on PD Response.
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>
Add a parameter allowing to specify a value of Coordination
Protocol Transport to P2PS_PROVISION and P2PS_PROVISION_RESP commands.
Extend the p2ps_provision structure to contain cpt_priority and
cpt_mask properties and initialize them on a P2PS PD request command.
The format of the parameter:
cpt=<cpt>[:cpt]
where <cpt> is CPT name e.g. UDP or MAC. The CPT names are listed
according to their preferences to be used for a specific P2PS session.
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>
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>
One possible outcome of the P2PS PD is P2P GO/P2P Client. In this case,
one peer becomes a P2P GO and the P2P Client joins it. Since multiple
GOs may run simultaneously on the same P2P Device, the P2P Client should
join using the intended interface address.
To be able to find the device by the intended interface address, save it
during the PD.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
If a device may be an explicit GO, it adds the GO details in the PD
Request. First, we try to reuse an active GO. If it is not present, we
try to reuse a non-active persistent group. In the latter case, if a
dedicated P2P interface is needed, the intended address should be that
of the pending interface. However, the wpas_get_go_info() provided the
ssid->bssid address, which is the address of the P2P device. This might
result in an incorrect intended interface attribute in the PD Request in
case a separate group interface is used.
Fix this by setting group_iface variable to true only if a dedicated
interface should be used and set the attribute accordingly.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Validate the PD Response frame contents more thoroughly when it is used
for P2PS.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
When persistent group is used and the peer is GO in this group,
intended interface attribute should be added to PD request/response.
Not doing so violates the spec.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
When device A sends PD response to device B, device A should save
wps_prov_info for device B. Not doing so would result in a redundant and
incorrect PD flow, e.g., when upon PROV-DISC-DONE event device B starts
a GO and device A should join it.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
In case of a P2PS PD, allow keypad, display, and P2PS WPS config
methods. For a legacy PD, allow keypad, display, and pushbutton methods.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Add 'else if' to P2PS status verification to prevent a redundant
condition checking. The first 'if' condition is true only if
status == P2P_SC_SUCCESS || status == P2P_SC_SUCCESS_DEFERRED.
while the second condition checks:
status != P2P_SC_SUCCESS &&
status != P2P_SC_FAIL_INFO_CURRENTLY_UNAVAILABLE &&
status != P2P_SC_SUCCESS_DEFERRED
Thus, the two conditions are mutually exclusive and 'else if' can be
used if this case.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Delete redundant comparison of msg.wps_config_methods with
dev->req_config_methods in p2p_process_prov_disc_resp() since it's
already done early in this function. Also, the second comparison
doesn't make too much sense: it can happen after a possible
p2p_reset_pending_pd() call setting dev->req_config_methods to 0.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
When wpa_supplicant receives a PD Response with reject status it
generated P2P-PROV-DISC-FAILURE event without adv_id and adv_mac
parameters. Fix this by adding these parameters to the
wpas_prov_disc_fail() function call.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Fix a condition when Advertised Service Info Attribute is added to
a probe response in p2p_buf_add_service_instance(). The issue is
that a 'found' value is increased even if 'test' and 'adv->hash' hashes
are different. As result 'found' may have a non-zero value when an
attribute data length is 0. In this cause an empty attribute is about to
be added. Fixing it by eliminating 'found' and checking 'total_len'
containing a real number of bytes added to Advertised Service Info
Attribute.
This fixes an issue from commit 50a9efe713
('P2PS: Fix Probe Response frame building in error cases').
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
It was possible for the P2PS Probe Response frame to go out on the
channel on which a Probe Request frame was reported even when we are
just about to start Listen mode on another channel. This could result in
the peer device using incorrect channel for us. Fix this by skipping the
response in this special case while waiting for Listen mode to start.
This showed up as a hwsim test failure with test sequence "gas_fragment
p2ps_connect_display_method_nonautoaccept" in cases where the dev[0]
Listen channel was not same as the AP operating frequency in the GAS
test.
Signed-off-by: Jouni Malinen <j@w1.fi>
The construction used here to figure out the offset of variable length
IEs in Probe Request frames was a bit odd looking and resulted in a
warning from a static analyzer, so replace it with more standard use of
offsetof().
Signed-off-by: Jouni Malinen <j@w1.fi>
p2p_process_nfc_connection_handover() allocates msg memory in the parser
and might return before memory is released if the received message is
not valid.
Signed-off-by: Ben Rosenfeld <ben.rosenfeld@intel.com>
org.wi-fi.wfds service is not a replacement for non-WFA service matches.
Do not try to replace the results with that if there is not sufficient
room for the response. Instead, reply with all the matching services
that fit into the message. org.wi-fi.wfds is the first entry in the list
(if matching request/service is present), so it won't get overridden by
other services.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The service hash for org.wi-fi.wfds is supposed to match only if the
device has a WFA defined org.wi-fi.wfds.* service. Verify that before
adding org.wi-fi.wfds to the response.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Probe Response building is already doing service matching and there is
no need to do this in both places, so simplify the p2p_reply_probe()
implementation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When doing initial processing of Probe Request frame service hashes, the
previous implementation dropped all other hash values if a hash for
org.wi-fi.wfds was included. This is not correct, since that is not a
full wildcard of all services (it only matches WFA defined
org.wi-fi.wfds.* services).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This "wildcard" match is for WFA specified org.wi-fi.wfds.* services,
not for all services. Verify that there is a really matching service
being advertised instead of assuming this "wildcard" matches if any
services are advertised.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The org.wi-fi.wfds "wildcard" is not a full wildcard of all service
names and as such, it must not remove other service name hash values
from the Probe Request frames.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
p2ps_gen_hash() has a limit on service names based on the temporary
buffer from stack. Verify that the service name from the local P2P_FIND
command is short enough to fix into that buffer.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Quoting P2PS specification: "If multiple Service Hash values are
included in the Probe Request frame, then the ASP shall find a match for
each Service Hash, and it shall send a Probe Response frame with the
information listed in this section for all matched Service Hashes." This
commit changes handling of wildcard hash matching by adding a
wildcard 'org.wi-fi.wfds' info together with the other hash matches.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Add auxiliary functions to write a single advertised service info record
into a wpabuf and to find P2PS wildcard hash in a received hash
attribute. Re-factor p2p_buf_add_service_instance() function to allow
adding new wildcard types in future commits.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Avoid using p2p_data::query_hash for both Probe Request frame processing
and for hashes specified by p2p_find. It's resolved by use of local
query_hash and query_count variables in p2p_reply_probe().
Since p2p_data::query_hash is used only for seek hash values rename
p2p_data::query_hash to p2ps_seek_hash.
Delete p2p_data::query_count since it's not needed anymore.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Commit 86bd36f0d5 ('Add generic mechanism
for adding vendor elements into frames') introduced a mechanism to add
vendor elements into various frames, but missed the addition to the
Invitation Response frame. This commit addresses the same.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This variable is used locally only in the p2p_reply_probe() function.
The value of this variable is valid only in the context of the single
Probe Request message handling and doesn't make much sense in p2p
context.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Free a PD context with a function encapsulating both os_free() call and
setting a PD context pointer to NULL.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
A P2P Client may be discoverable and reply to Probe Request frames,
while at the same time the P2P GO would also be discoverable and include
the P2P Client information in the P2P Group Info attribute of the Probe
Response frames.
If a seeker constantly hears the Probe Response frames from a P2P Client
and then from the GO, but handles them in the opposite order (due to
scan results ordering), the more valuable Probe Response frame from the
P2P Client will be ignored. Fix this by defining a threshold (1 second)
during which the direct Probe Response frame will be preferred over the
information acquired from the GO and will not be considered as old.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
When adding group clients to the P2P peer list, use the driver provided
BSS entry timestamp instead of the current time. Otherwise, the time
comparison which is made in p2p_add_device() doesn't make sense.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
If the RX frequency of the Probe Request frame is known, specify it when
sending the Probe Response frame. This is needed when the Probe Request
frame is received on another virtual interface, for example, when a GO
or P2PS client are discoverable on the group operating channel.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Return P2P_PREQ_PROCESSED instead of P2P_PREQ_NOT_PROCESSED on
a successful Probe Request frame handling in p2p_reply_probe().
Verify a return value of p2p_reply_probe() in p2p_probe_req_rx()
and continue a pending invitation/connection flow only if the
Probe Request frame is from an expected P2P peer.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
In some cases, Probe Request frames can be received by a peer not only
on a listen channel. In this case an additional rx_freq parameter
explitly contains a Probe Request frame RX frequency. In case rx_freq is
set to 0, a Probe Request frame RX channel is assumed to be our own
listen channel (p2p->cfg->channel).
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Add operating class 125 (channels 149..169) to the list of P2P supported
channels. This allows the 5 GHz channels 161 and 169 to be used for P2P
GO when those channels are allowed for AP mode in the current regulatory
domain.
Signed-off-by: Amr BEN ABDESSALEM <amrx.ben.abdessalem@intel.com>
Add GO Intent information of connecting device in GO Negotiation Request
event which will help applications to decide its own GO intent value in
advance and can avoid failure cases when both devices use GO Intent 15
depending on application requirement.
Signed-off-by: Mayank Haarit <mayank.h@samsung.com>
Do not add a P2P IE when a station interface is trying to associate
to an AP or P2P GO that publishes a P2P IE but does not include
a P2P manageability attribute.
This addresses an interoperability issue that was reported in
https://bugzilla.kernel.org/show_bug.cgi?id=96471, where a P2P GO
rejects association from a station interface without a specified
reason.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
This enforces variable length strings Manufacturer, Model Name, Model
Number, and Serial Number to be within the maximum length defined in the
WSC specification. While none of the existing users for these within
hostapd/wpa_supplicant had problems with longer strings, it is good to
ensure the strings are not longer to avoid potential issues at higher
layer components.
Signed-off-by: Jouni Malinen <j@w1.fi>
Check the element length in the parser and remove the length field from
struct ieee802_11_elems since the only allowed element length is one.
Signed-off-by: Jouni Malinen <j@w1.fi>
This program can be used to run fuzzing tests for areas related to P2P
message parsing and processing. p2p-fuzzer allows data files to be used
to inject Probe Response and Action frames for processing by the P2P
module.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it more obvious that the wps_parse_msg() bounds checking is
used to verify that there is sufficient space in the P2P buffer for the
secondary device types.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
