Each GO Negotiation Request is (re)tried with an unique dialog token and
a GO Negotiation Response / Confirmation from the peer with a mismatched
dialog token is ignored which could result in a failure in this group
formation attempt. Thus, the P2P device would continue retrying the GO
Negotiation Request frames till the GO Negotiation Response frame with a
matching dialog token is received. To avoid the failures due to the
dialog token mismatch in retry cases if the peer is too slow to reply
within the timeout, the same dialog token value is used for every retry
in the same group formation handshake.
It should be noted that this can result in different contents of the GO
Negotiation Request frame being sent with the same dialog token value
since the tie breaker bit in GO Intent is still toggled for each
attempt. The specification is not very clear on what would be the
correct behavior here. Tie breaker bit is not updated on
"retransmissions", but that is more likely referring to the layer 2
retransmission and not the retry at higher layer using a new MMPDU.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This commit increases the maximum buffer size for P2P Client Info
advertized by the Group Owner in the Probe Response frames.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 175171ac6c ensured that the PD
requests are retried in join-a-running group case and the Enrollee is
started on either receiving the PD response or after the retries. Each
PD request is retried with an unique dialog token and a PD response from
the GO with a mismatched dialog token is ignored. Thus, the P2P client
would continue retrying the PD requests till the response with a
matching dialog token is obtained. This would result in the GO getting
multiple PD requests and a corresponding user notification (POP UP) in
implementations where each PD request results in a POP UP, resulting in
a bad user experience. To avoid such behavior, the same dialog token
value is used for every retry in the same PD exchange.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This makes it easier to read the code for the two possible cases
(forced/preferred channel and automatic channel selection).
Signed-hostap: Jouni Malinen <j@w1.fi>
Since the operating channel is randomly set to 1/6/11 on init, which is
commonly included in the channel intersection, we were effectively
ignoring the set of P2P preferred channels when trying to improve
channel selection after having received peer information. Fix this by
trying to get the best channel we can, unless the user hard coded the
operating channel in the configuration file or p2p_connect command. Fall
back to the initial randomly selected channel if a better one cannot be
chosen.
Signed-hostap: Arik Nemtsov <arik@wizery.com>
Even if the peer does not accept the forced channel, we should not allow
the forced_freq parameter to be be overridden, i.e., such a case needs
to result in GO Negotiation failure.
Signed-hostap: Jouni Malinen <j@w1.fi>
Both p2p_connect and p2p_authorize use the same functionality to select
the channel preferences for GO Negotiation. The part of setting this
device flag was copied to each function, but it can also be handled by
the shared function after some reordering of code.
Signed-hostap: Jouni Malinen <j@w1.fi>
The exact same mechanism was used for determining the operating channel
at the device that becomes the GO regardless of whether this was
triggered by reception of GO Negotiation Request of Response frame. Use
a shared function to avoid duplicated implementation and potential
differences in the future.
Signed-hostap: Jouni Malinen <j@w1.fi>
When no other user preference is specified, opt to use an operating
channel that allows HT40 operation. This way, if driver capabilities
and regulatory constraints allow, we might enjoy increased bandwidth.
Signed-hostap: Arik Nemtsov <arik@wizery.com>
cfg80211 caches the scan results according the channel number. Due to
the 15 sec aging this might cause the user mode to see more than one
scan result with the same BSSID, e.g. - one scan result for the
P2P Device and one for the P2P GO (once it's enabled).
Fix this by updating the device entry only if the new peer entry is
newer than the one previously stored.
Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com>
Signed-off-by: Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Igal Chernobelsky <igalc@ti.com>
Signed-hostap: Arik Nemtsov <arik@wizery.com>
Change the maximum retry limit from 10 to 120 to match the behavior
used with GO Negotiation Request frames when trying to start GO
Negotiation with a peer that does not acknowledge frames (e.g., due
to being in sleep or on another channel most of the time).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The GO may be in sleep when we send a PD Request frame to indicate that
we are about to join a running group. Previously, this frame was not
retried more than normal low level retries. This can result in the GO
not getting the frame especially in cases where concurrent multi-channel
operations or aggressive sleep schedule is used since most drivers do
not yet synchronize with the GO's NoA before association.
Increase the likelihood of the GO receiving the PD Request frame by
retransmitting it similarly to the PD-for-GO-Negotiation case. Start
the actual join operation only after these retries have failed to get
an acknowledgment from the GO to give the connection attempt a chance
to succeed if the driver implements better NoA synchronization for it.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_prov_disc_req() used the join parameter to figure out whether the PD
request was a user initiated or not. This does not cover all use cases
of PD, so add a separate parameter to allow caller to indicate whether
the user requested the operation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The PSK generation done by pbkdf2_sha1() is one of the longest CPU time
users according to our profiling from boot to GO started.
So I have reduced some steps.
I could boot a GO by this command sequence.
-------------
add_net
set_network 0 ssid '"DIRECT-XX"'
set_network 0 psk
'"123456789012345678901234567890123456789012345678901234567890123"'
set_network 0 proto RSN
set_network 0 key_mgmt WPA-PSK
set_network 0 pairwise CCMP
set_network 0 auth_alg OPEN
set_network 0 mode 3
set_network 0 disabled 2
p2p_group_add persistent=0 freq=2412
-------------
By this sequence, pbkdf2_sha1() was called three times and the function
calculates the same value each time. Reduce number of calls to
pbkdf2_sha1() from 3 to 1 by caching the previous result.
Signed-hostap: Masashi Honma <masashi.honma at gmail.com>
The new P2P_SET parameter disc_int can now be used to configure
discoverable interval for p2p_find operations. The format of the command
for setting the values is "P2P_SET disc_int <minDiscoverableInterval>
<maxDiscoverableInterval> <max TUs for discoverable interval>". The
first two parameters are given in units of 100 TUs (102.4 ms). The third
parameter can be used to further limit the interval into a specific TU
amount. If it is set to -1, no such additional limitation is enforced.
It should be noted that the P2P specification describes the random
Listen state interval to be in units of 100 TUs, so setting the max TU
value to anything else than -1 is not compliant with the specification
and should not be used in normal cases. The default parameters can be
set with "P2P_SET disc_int 1 3 -1".
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If the driver indicates support for multi-channel concurrency, change
the p2p_connect behavior to not force the current operating channel, but
instead, just mark it as preferred for GO Negotiation. This change
applies only for the case when the freq parameter is not used with the
p2p_connect command.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
P2P includes two use cases where one of the devices is going to start a
group and likely change channels immediately after processing a frame.
This operation may be fast enough to make the device leave the current
channel before the peer has completed layer 2 retransmission of the
frame in case the ctrl::ack frame was lost. This can result in the peer
not getting TX status success notification.
For GO Negotiation Confirm frame, p2p_go_neg_conf_cb() has a workaround
that ignores the TX status failure and will continue with the group
formation with the assumption that the peer actually received the frame
even though we did not receive ctrl::ack. For Invitation Response frame
to re-invoke a persistent group, no such workaround is used in
p2p_invitation_resp_cb(). Consequently, TX status failure due to lost
ctrl::ack frame results in one of the peers not starting the group.
Increase the likelihood of layer 2 retransmission getting acknowledged
and ctrl::ack being received by waiting a short duration after having
processed the GO Negotiation Confirm and Invitation Response frames for
the re-invocation case. For the former, use 20 ms wait since this case
has been worked around in deployed devices. For the latter, use 50 ms
wait to get even higher likelihood of getting ctrl::ack through since
deployed devices (and the current wpa_supplicant implementation) do not
have a workaround to ignore TX status failure.
20 ms is long enough to include at least couple of retries and that
should increase likelihood of getting ctrl::ack through quite a bit. The
longer 50 ms wait is likely to include full set of layer 2 retries.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 6b56cc2d97 added clearing of the
p2p->pending_action_state too early in this function. This should not
be done if we are going to silently ignore the frame due to dialog
token mismatch. Fix this by moving the code around to check the dialog
token first.
This issue resulted in PD Request retries getting stopped too early if
the peer is sending out an unexpected PD Response (e.g., because of it
being excessively slow with the response so that the response is
received only after the next TX attempt with a new dialog token).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Make Invitation process for re-invoking a persistent group behave
similarly to GO Negotiation as far as channel negotiation is concerned.
The Operating Channel value (if present) is used as a starting point if
the local device does not have a forced operating channel (e.g., due to
concurrent use). Channel lists from devices are then compared to check
that the selected channel is in the intersection. If not, channel is
selected based on GO Negotiation channel rules (best channel preferences
etc.). Invitation Request is rejected if no common channel can be
selected.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The group matching should be done by comparing the P2P Interface Address
(which the group_bssid here is) to the group's BSSID and not the group
ID (which uses P2P Device Address and would have also needed the SSID).
Though, it should be noted that this case cannot really happen since a
GO in an active group would never be invited to join another group in
its GO role (i.e., if it receives an Invitation Request, it will reply
in P2P Device role). As such, this fix does not really change any
observable behavior, but anyway, it is good to keep the implementation
here consistent with the Invitation Request case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When building the Invitation Request for WFD use cases, match the BSSID,
i.e., P2P Interface Address, of the group on the GO to avoid using
information from another group should the device be operating multiple
concurrent groups as GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
wpa_cli p2p_serv_disc_req command can now be used to request WSD
request to be sent to specified or all peers who support WSD.
format: wifi-display <list of roles> <list of subelements>
examples:
p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source] 2,3,4,5
p2p_serv_disc_req 02:01:02:03:04:05 wifi-display [pri-sink] 3
p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [sec-source] 2
p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source+sink] 2,3,4,5
p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source][pri-sink] 2,3,4,5
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This commit adds control interface commands and internal storage of
Wi-Fi Display related configuration. In addition, WFD IE is now added
to various P2P frames, Probe Request/Response, and (Re)Association
Request/Response frames. WFD subelements from peers are stored in the
P2P peer table.
Following control interface commands are now available:
SET wifi_display <0/1>
GET wifi_display
WFD_SUBELEM_SET <subelem> [hexdump of length+body]
WFD_SUBELEM_GET <subelem>
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 488f4a7108 configures a timer
before p2p_send_action(). This may result in the timer getting fired
earlier to the off channel transmission of the frame and thus another PD
request being retransmitted. This shall lead to the new PD request with
an incremented dialog token being transmitted. For the cases where the
later PD request might not be transmitted as the host driver is busy
transmitting the earlier frame, the received PD response could be
dropped for the dialog token mismatch. Remove the timer configuration to
avoid this behavior.
Signed-hostap: Sunil Dutt Undekari <duttus@codeaurora.org>
intended-for: hostap-1
Previously, all station mode scan operations were either skipped or
delayed while any P2P operation was in progress. To make concurrent
operations easier to use, reduce this limitation by allowing a scan
operation to be completed in the middle of a p2p_find. In addition,
allow station mode association to be completed. When the station mode
operation is run to its completion (scan results not acted on,
connection to an AP completed, connection failed), resume the p2p_find
operation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
A new optional delay=<search delay in milliseconds> parameter can now be
used with p2p_find command to request an extra delay between search
iterations. This can be used, e.g., to make p2p_find friendlier to
concurrent operations by avoiding it from taking 100% of the radio
resources.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Increase GO config timeout if HT40 is used since it takes some time
to scan channels for coex purposes before the BSS can be started.
Signed-hostap: Jouni Malinen <j@w1.fi>
Add optional "ht40" argument for p2p_group_add command to enable 40 MHz
in 5GHz band. This configures the secondary channel, when HT support is
enabled and if the HW supports 40 MHz channel width.
Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
p2p_set_timeout() calls in GO Neg Req/Resp TX callbacks used timeout of
100 ms which is the value given in the P2P specification for GO
Negotiation, but this was actually shorter than the
wait-for-offchannel-TX value (200 ms) used for the driver call. In
addition, it looks like some devices (e.g., Galaxy Nexus with JB image)
can take longer time to reply to GO Negotiation Response (somewhere
between 200 and 250 ms has been observed).
Increase the wait-for-GO-Neg-Resp timeout from 100 ms to 200 ms if GO
Negotiation Request frame was acknowledged (this matches with the
offchannel wait timeout that used previously). The no-ack case is left
at 100 ms since we use GO Negotiation Request frame also to discover
whether the peer is on its Listen channel.
Increase the wait-for-GO-Neg-Conf timeout from 100 ms to 250 ms (and
increase the offchannel wait timeout to matching 250 ms) as a workaround
for devices that take over 200 ms to reply to GO Negotiation Response.
Signed-hostap: Jouni Malinen <j@w1.fi>
Commit 6b56cc2d97 added retries of
provision discovery request frames in IDLE state. However, it did not
make the p2p_find case behave consistently with the new limitied retry
behavior. This can result in way too many and frequent PD retries. Fix
this by extending the previous commit to address PD retries and maximum
retry limit consistently regardless of whether p2p_find is running.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
This patch adds a check of the return value of wpabuf_dup() in a large
Service Discovery Response.
Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
There are separate states for these, so we can't really get into this
situation unless somebody tries to do multiple things at the same
time. p2p_connect stops find and CONNECT state is used to probe the peer
on its Listen channel with GO Negotiation Request frames. Similarly,
p2p_invite() stops find and INVITE state is used to probe the peer on
its Listen channel with Invitation Request frames. The older mechanism
of using Search state functionality to find the peer can be removed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, FullMAC Persistent GO can't use p2p_client_list because its
own hapd->p2p_group is NULL at ap_sta_set_authorized(). This patch
changes the processing to use sta->p2p_ie instead of
p2p_group_get_dev_addr() on FullMAC GO.
Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
The P2P Client Discoverability bit is reserved in most frames and its
value in the local P2P peer table should only be updated based on P2P
Group Info attribute from a GO. Fix this by avoiding changes to this
dev_capab bit based on other P2P frames. It would be more correct to
track this separately for each group in which the peer is a member, but
since we do not do that for the other group specific information either,
this can do for now.
It should be noted that prior to commit
18485b5469 wpa_supplicant set this bit in
all P2P frames. However, that commit changed this to match the
specification, i.e., the bit is not set in frames which are received
from P2P Device role. As such, this fix is needed to be able to figure
out that a peer supports client discoverability capability after that
commit.
Signed-hostap: Jouni Malinen <j@w1.fi>
intended-for: hostap-1
In the P2P specification v1.1, the P2P Client Discoverability bit is
described in Table 12 "Device Capability Bitmap definition". The table
says "Within a P2P Group Info attribute and a (Re)association request
frame the P2P Client Discoverability field shall be set to 1 when the
P2P Device supports P2P Client Discoverability, and is set to 0
otherwise. This field shall be reserved and set to 0 in all other frames
or uses.". To match with this, filter out P2P Client Discoverability bit
from frames where its use is reserved.
Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
There is a race condition in GO Negotiation Request frame sending and
processing that may end up with both devices sending GO Negotiation
Response. This response frame was previously accepted even if a response
had already been sent. This could result in two GO Negotiation Confirm
frames being exchanged and consequently, with two separate GO
Negotiations completing concurrently. These negotiations could result in
getting mismatching parameters (e.g., both device could believe it was
the GO).
Fix this by ignoring GO Negotiation Response from the peer if twe have
already sent a GO Negotiation Response frame and we have the higher P2P
Device Address. This is similar to the rule used to determine whether to
reply to GO Negotiation Request frame when Request was already sent,
i.e., the same direction of GO Negotiation is maintained here to enforce
that only the negotiation initiated by the device with smaller P2P
Device Address is completed.
Signed-hostap: Jouni Malinen <j@w1.fi>
intended-for: hostap-1
If both peers initiate GO Negotiation at about the same time, it is
possible for the GO Negotiation Request frame from the peer to be
received between the local attempt to send the GO Negotiation Request
and TX status event for that. This could result in both devices sending
GO Negotiation Response frames even though one of them should have
skipped this based which device uses a higher MAC address.
Resolve this race by incrementing go_neg_req_sent when p2p_send_action()
returns success instead of doing this from the TX status callback. If
the frame is not acknowledged, go_neg_req_sent is cleared in TX status
handler.
Signed-off-by: Neeraj Garg <neerajkg@broadcom.com>
Stop the connection attempt if GO Negotiation Confirm is not received
within 100 ms of the GO Negotiation Response getting acknowledged.
Previously, we would have continued trying to connect to the peer even
in this case which could result in confusing second GO Negotiation
Request frame and unnecessarily long wait before indicating failure.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The GO Negotiation Confirm frame doesn't need to be sent with a wait
since we don't expect a response to it.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Concurrent Operation bit was not set for GO even if the device
supports concurrent operations. Make sure the Device Capability
value is consistent with other P2P use cases by using the value
determined in p2p_init().
Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
This is a workaround for interoperability issues with some deployed P2P
implementations that require a Provision Discovery exchange to be used
before GO Negotiation. The new provdisc parameter for the p2p_connect
command can be used to request this behavior without having to run a
separate p2p_prov_disc command.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If PD Request includes P2P Group ID, verify that the specified
group matches with a group we are currently operating. If no match
is found, reject the PD Request for join-a-group case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This can be used with P2P management operations that need to verify
whether the local device is operating a specific group based on
P2P Group ID attribute from a peer.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 349b213cc8 added a separate
callback prov_disc_fail() for indicating PD failures, but it left the
Provision Discovery Response handler to call both callbacks in case the
peer rejected the PD. Commit f65a239ba4
added ctrl_iface event for PD failures. This combination can result in
two ctrl_iface events in the peer rejecting a PD case. Clean this up by
only indicating the failure event.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
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 could result in continuous
loop of search/listen states with very limited time to do anything else
in wpa_supplicant if the scan command is also completed quickly (e.g.,
if the driver is unable to scan other channels than the current
operating channel).
As a workaround, do not start the next step (search) in P2P device
discovery if this type of rejection of listen operation is detected.
This gives some more time for wpa_supplicant to handle whatever else
may be needed at to be done at the same time and reduces the amount
of CPU used in a loop that does not really work correctly from the
view point of being discoverable.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
