This makes it easier to go through the P2P channel list operations in
the debug log without having to parse through the hexdump manually.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This fixes issues where a GO used offchannel-TX operation to send an
Invitation Request frame. Wait for the offchannel TX operation needs to
be stopped as soon as the Invitation Response frame has been received.
This addresses some issues where Probe Response frame from the GO
through the monitor interface may end up going out on a wrong channel
(the channel of this offchannel TX operation for invitation).
Signed-hostap: Jouni Malinen <j@w1.fi>
Join-a-group needs to force the current operating channel of the target
group as the frequency to use for the PD exchange. When the channel was
selected based on a BSS entry for the GO, this worked only for the first
PD Request frame while the retries reverted to a potentially different
channel based on a P2P peer entry. Fix this by maintaining the forced
channel through the PD retry sequence.
Signed-hostap: Jouni Malinen <j@w1.fi>
P2P Invitation Response frame is required to include the Channel List
attribute only in Status=Success case. Skip the debug message claiming
that a mandatory attribute was not included in non-Success case.
Signed-hostap: Jouni Malinen <j@w1.fi>
In noisy environment peer may take more time to send Invitation
Response so increase Invitation Response timeout to 500 ms in success
case and also increase Invitation Request action wait time to 500 ms.
This makes the Invitation Request case use the same timeout with GO
Negotiation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When no other user preference is specified, opt to use an operating
channel that allows 5 GHz band to be used rather than 2.4 GHz.
Previously, this was already done in practice for HT40 channels since no
such channel is enabled for P2P on 2.4 GHz. This commit extends this to
apply 5 GHz preference for 20 MHz channels as well.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Even after listen duration is over, P2P module remained in
P2P_LISTEN_ONLY state, which is blocking station mode scans. Fix this by
stopping P2P listen explicitly to update p2p_state to IDLE when listen
duration expires.
Signed-hostap: Syed Asifful Dayyan <syedd@broadcom.com>
If the device that sends the GO Negotiation Confirm becomes the GO, it
may change its operating channel preference between GO Negotiation
Request and Confirm messages based on the channel list received from us.
Previously, the peer operating channel preference was not updated in
such a case and this could result in the initial scans after GO
Negotiation using incorrect operating channel and as such, extra delay
in the connection process. Fix this by updating the operating channel
information from GO Negotiation Confirm in cases where the peer becomes
the GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If there are no higher priority preference for the operating channel,
use the first pref_chan entry as the operating channel preference over
the pre-configured channel which is not really a good indication of
preference. This changes the behavior for GO Negotiation Request frame
operating channel preference value in cases where p2p_pref_chan list is
set.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Add additional input verification for the frequency parameter in
p2p_group_add (and other P2P operations for that matter). Without this
verification invalid freq could be set and not handled properly.
Signed-hostap: Ilan Peer <ilan.peer@intel.com>
If AP mode SME/MLME within wpa_supplicant is used for processing Probe
Request frames in GO mode, drop Probe Request frames that include only
802.11b rates per P2P spec section 2.4.1.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
In a noisy enviromment, some peers can be slow to respond to the
invitation request frames which may lead to unnecessary state timeout.
Increase this timeout to 350 ms to improve the probabilty of
successfully receiving the invitation response frames.
Signed-hostap: Vivek Natarajan <nataraja@qca.qualcomm.com>
When STA interface is connected and P2P interface gets invited in a
different channel from previous P2P group, the invitiation would fail
because of no common channel found. Fix this by using different logic
when device support multi channel concurrency.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Replace direct wpa_msg() calls with p2p_dbg(), p2p_info(), and p2p_err()
calls that use a new debug_print() callback to handle actual debug
printing outside the P2P module.
Signed-hostap: Jouni Malinen <j@w1.fi>
This removes wpa_ctrl.h dependency from src/p2p/* and makes the P2P
events more consistent, i.e., everything that is aimed for upper layer
processing from the wpa_supplicant control interfaces is generated in
p2p_supplicant.c.
Signed-hostap: Jouni Malinen <j@w1.fi>
Allow invitation exchange to update operating channel selection after
peer channel list has been received similarly to how GO negotiation was
handled.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
All P2P use cases are required to use the global operating table and
there is no need to need to try to maintain some backwards compatibility
with country code -specific values. Clean up the implementation by
removing the unnecessary country parameter.
Signed-hostap: Jouni Malinen <j@w1.fi>
Commit fb8984fd6f added a mechanism to
skip the Listen state when the peer is expected to be waiting for us to
initiate a new GO Negotiation. However, this flag was set when building
the GO Negotiation Response frame with status 1 regardless of whether we
managed to send that frame or peer receive it. This could result in GO
Negotiation failures in cases where the peer did not receive the
response and Listen channels of the devices were different. Fix this by
setting the flag only after TX status indicating success has been
received.
This fixes frequent failures shown for the test_grpform_pbc hwsim test
case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When Action frame TX is postponed until a pending p2p_scan completes,
there may be additional operations that need to be continued after the
postponed Action frame TX operation completes. Fix this by starting
pending operation (if any) from TX status event for after_scan_tx
frames.
This fixes common errors seen with the test_discovery hwsim test case.
Signed-hostap: Jouni Malinen <j@w1.fi>
As per P2P specification v1.2: "The P2P Group Info attribute shall be
omitted if there are zero connected P2P Clients."
Do not add the attribute if there are not connected peers.
Signed-hostap: Chaitanya T K <chaitanya.mgit@gmail.com>
Commit 6b56cc2d97 added a possible call to
p2p_reset_pending_pd() prior to checking config_methods match between
our request and peer response. That reset call could clear
dev->req_config_methods and as such, result in unexpected
P2P-PROV-DISC-FAILURE report here even in cases where the peer accepts
the provision discovery. Fix this by using a local copy of the
req_config_methods variable.
Signed-hostap: Jouni Malinen <j@w1.fi>
In some cases where the ack for Invitation response is lost,
the device is stuck in invited state but the peer device starts
GO. In line with the implementation of Negotiation Confirm,
assume invitation response was actually received by the peer
even though ack was not reported.
Signed-hostap: Vivek Natarajan <nataraja@qca.qualcomm.com>
Previously, P2P_PD_DURING_FIND state was scheduled for 200 ms and the
P2P state was not change until that timeout regardless of whether the PD
Response for recieved or not. There is no need to wait for that timeout
if the response is received, so allow the next operation to be performed
immediately after the response has been processed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If a peer replies to persistent group invitation with status code 8
(unknown group), remove the peer from the p2p_client_list if we are the
GO or remove the persistent group if we are the P2P client since it
looks like that the peer has dropped persistent group credentials and
the provisioning step needs to be executed again.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 50285f5ca8 changed number of rules
in channel selection and among other things, it broke the design where
the currently used operating channel on a virtual interface that is
shared by the same radio is preferred to avoid costs related to
multi-channel concurrency. Fix this regression by making the P2P module
aware of the shared channel and using that preference as the highest
priority when re-selecting the channel during negotiation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 50285f5ca8 ended up forcing channel
re-selection in number of cases where the peer would actually have
accepted our initial preference. Fix the parts related to best channel
information by using best_freq_overall as the highest priority and by
skipping the band changes if the peer supports the channel that we
picked since these were based on the assumption that
p2p_reselect_channel() is called only if the peer could not accept our
initial choice which is not the case anymore.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for a P2P client to connect to an operating group without
exchanging any Probe Request/Response frames that would allow the GO to
discover the peer. To make sure there is a P2P peer entry at the GO, try
to add the peer information based on P2P IE in (Re)Association Request
frame.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Peer device includes its list of allowed operating channels in the
Invitation Response frame. When we are becoming the GO, use that list
from the peer to filter out acceptable channels to avoid selecting a
channel that the peer is unable to use.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When re-invoking a persistent group in P2P client role, the new
pref=<MHz> parameter can now be used with the p2p_invite command to
indicate a preferred operating frequency. Unlike the older freq=<MHz>
parameter, this leaves GO an option to select another channel (from our
supported channels) if the GO cannot accept the channel.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If multi channel concurrency is supported, we have to populate the
p2p_channels with list of channels that we support. Use the same design
that was previously added for GO Negotiation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit fb8984fd6f cleared wps_method to
WPS_NOT_READY in p2p_stop_find_for_freq() as an attempt to clear
authorization when a group formation is cancelled. However, this code
path is hit also in cases where the user did not actually cancel
anything (e.g., from p2p_process_go_neg_req()). As such, it is not fine
to clear wps_method here even if it could be proper for some cases. For
now, revert that part to avoid regressions and consider clearing
wps_method on cancel separately.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
In case we have replied to a peer's GO Negotiation Request frame with a
GO Negotiation Response frame using status code
info-currently-unavailable (1), the peer is likely going to wait for us
to initiate GO Negotiation on its Listen channel. We were previously
using alternativing send-GO-Neg-Req and Listen phase when providing that
response after the user had authorized the connection. However, the
Listen phase here is unnecessary in this case and will make the
connection take longer time to go through. Skip the Listen phase and
make the wait-for-GO-Neg-Resp timeout random between 100 and 200 ms to
avoid getting in sync with the peer. In practice, this will make us
retry GO Negotiation Request frames more frequently and remain on the
peer's Listen channel for most of the time when initiating GO
Negotiation after status=1 response.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
There may be environments in which large number of devices are operating
on the social channels. In such cases, it is possible for the Action
frame TX operation wait for quite long time before being able to get the
frame out. To avoid triggering GO Negotiation failures, increase the
timeouts for GO Neg Req (with TX ACK) and GO Neg Resp (with or without
TX ACK as long as status=0) to 500 ms.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for the driver to indicate multiple Probe Request frames
that would be processed in a single loop. If those frames happen to be
from a peer which with we are trying to start GO Negotiation, multiple
timeouts to start GO Negotiation (p2p_go_neg_start) could end up being
scheduled. This would result in confusing burst of multiple GO
Negotiation Request frames being sent once the RX loop finally
concludes. Avoid this by scheduling only a single eloop timeout to
trigger GO Negotiation regardless of how many Probe Request frames from
the peer is received. In addition, make sure this timeout gets canceled
in p2p_deinit().
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If we have already sent out GO Negotiation Response and are waiting for
the peer to reply with GO Negotiation Confirm, there is no point in
re-starting GO Negotiation based on Probe Request frame from the peer.
Doing that would just result in confusing GO Negotiation exchange with
multiple sessions running at the same time.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The device that is selected as the GO shall incode P2P Group ID
attribute in GO Negotiation Response/Confirm message. Previously we did
not reject a message without that attribute since it was possible to
continue operations even without knowing the SSID. However, this can
potentially result in confusing results since missing P2P Group ID
attribute can be a sign of conflicting GO role determination (both
devices assuming the peer is the GO). To get clearer end result for the
GO Negotiation, reject this as a fatal error. In addition, stop GO
Negotiation if GO Negotiation Confirm indicates non-zero status since
that is also a fatal error.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 624b4d5a64 changed GO Negotiation
to use the same Dialog Token value for all retransmissions of the GO
Negotiation Request within the same session. However, it did leave the
tie breaker bit changing for each frame. While this should not have
caused issues for most cases, it looks like there are possible sequences
where the peer may end up replying to two GO Negotiation Request frames
with different tie breaker values. If in such a case the different GO
Negotiation Response frames are used at each device, GO role
determination may result in conflicting results when same GO intent is
used.
Fix this by assigning the tie breaker value at the same time with the
dialog token (i.e., when processing the p2p_connect command instead of
for each transmitted GO Negotiation Request frame) to avoid issues with
GO selection.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The driver may have cached (e.g., in cfg80211 BSS table) the scan
results for relatively long time. To avoid reporting stale information,
update P2P peers only based on results that have based on frames
received after the last p2p_find operation was started.
This helps especially in detecting when a previously operating GO stops
the group since the BSS entry for that could live for 30 seconds in the
cfg80211 cache. Running p2p_flush followed by p2p_find will now allow
wpa_supplicant to not add a P2P peer entry for that GO if the group had
been terminated just before that p2p_flush command. Previously, that GO
could have been indicated as a newly found device for up to 30 seconds
after it had stopped the group.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
For various P2P use cases, it is useful to have more accurate timestamp
for the peer information update. This commit improves scan result
handling by using a single timestamp that is taken immediately after
fetching the results from the driver and then using that value to
calculate the time when the driver last updated the BSS entry. In
addition, more debug information is added for P2P peer updates to be
able to clearly see how old information is being used here.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If we discover a P2P peer based on a Beacon frame from the GO role, we
do not get information about the supported configuration methods. This
can result in issues if the P2P managing entity above wpa_supplicant is
not prepared to handling config_methods=0x0. To avoid this, postpone
reporting of the P2P-DEVICE-FOUND event when this happens on one of the
social channels. It would be good to be able to this on all channels,
but that could result in issues of never indicating the event for a peer
that is operating a GO on a channel that requires passive scanning.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It could be possible for the scan results to include two entries for a
peer, one from the Listen state and the second one from the GO role. The
latter could be based on a Beason frame. If that happens and the entry
from GO is processed last, the P2P peer config_methods value could
potentially get cleared since Beacon frames do not include this
information in either WPS or P2P element. Avoid this by allowing the
config_methods value for P2P peers to be updated only if the new value
is non-zero.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When pending p2p_find fails we need to send p2p_stop_find event to
indicate the previous p2p_find command has been processed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 1a9f6509b3 added support for
fragmenting the P2P IE in Probe Response frames from a GO. However, it
did not take into account the possibility of Wi-Fi Display IE being
included in the same buffer and caused a regression for the cases where
Wi-Fi Display is enabled. Fix this by building the possibly fragmented
P2P IE first and then concatenating the separate IEs together.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The P2P-FIND-STOPPED event was sent only in the P2P_SEARCH state, but
this needs to be send also in the new continue-search-when-ready states
P2P_CONTINUE_SEARCH_WHEN_READY and P2P_SEARCH_WHEN_READY for consistent
behavior.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
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
The misplaced parenthesis caused Device ID matching to check only the
first octet of the P2P Device Address, i.e., we could have replied to
Probe Request frames that was searching for another device if any of
the last five octets of the address were different.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
An existing persistent group information can now be used to force GO
Negotiation to use the previously used SSID/passphrase from a persistent
group if we become a GO. This can be used as an alternative to inviting
a new P2P peer to join the group (i.e., use GO Negotiation with GO
intent 15 instead of starting an autonomous GO and using invitation),
e.g., in case a GO Negotiation Request is received from a peer while we
are not running as a GO. The persistent group to use for parameters is
indicated with persistent=<network id> parameter to p2p_connect.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commits 17bef1e97a and
ffe98dfb88 started using p2p_add_device()
with other frames than just Probe Response frames from scan results.
However, these changes did not take into account that the PD Request
and Invitation Request frames are normally received on the our own
Listen channel, not on the Listen channel of the peer. As such, these
frames must not be used to update Listen channel information for the
peer.
Fix this by letting p2p_add_device() know whether the results are from
scan results and if not, skip the peer table updates that are specific
to Probe Response frames.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
Commit d9bdba9f86 was supposed to allow
p2p_listen to schedule new after scan operation only if a p2p_connect
operation was not pending. However, it used incorrect P2P_AFTER_SCAN_
value for this and did not actually prevent overriding of p2p_connect
and could have caused some p2p_listen operations to be skipped
unnecessarily.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
Unlike the unicast SD queries, the queries directed to all peers depend
on P2P_DEV_SD_INFO flag being cleared to allow the query to be sent to
a peer that has previously replied to any SD query.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Some applications require knowing about probe requests to identify
devices. This can be the case in AP mode to see the devices before they
connect, or even in P2P mode when operating as a P2P device to identify
non-P2P peers (P2P peers are identified via PeerFound signals).
As there are typically a lot of probe requests, require that an
interested application subscribes to this signal so the bus isn't always
flooded with these notifications. The notifications in DBus are then
unicast only to that application.
A small test script is also included.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
The "BSS p2p_dev_addr=address" command uses p2p_parse_dev_addr() to
figure out the P2P Device Address of the GO from scan results. This used
to work only if the P2P IE was received from Probe Response frames since
only those include the P2P Device Info attribute. Make this work with
Beacon frames, too, by using P2P Device ID attribute if the P2P Device
Info attribute is not present.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_pref_chan configuration parameter can now be used to set the
list of preferred channel for P2P GO Negotiation. This will be used
in the priority order if the peer does not support the channel we
are trying to use as the GO (configured operating channel or the
best 2.4 GHz/5 GHz channel) for the case where a forced channel is
not used.
p2p_pref_chan=<op class:channel>,...
For example:
p2p_pref_chan=81:1,81:2,81:3,81:4,81:5,81:6
This would configure 2.4 GHz channels 1-6 as the preferred ones with
channel 1 the most preferred option.
These configuration parameters can be set in wpa_supplicant.conf and
dynamically updated with "wpa_cli set <param> <value>".
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, this provisioning info was cleared using the P2P Interface
Address of the GO as the key. That did not always work in the case the
where we joined an already running group. This could result in the next
connection to that same GO skipping provision discovery. Fix this by
finding the peer entry based on its P2P Device Address instead of the
P2P Interface Address which may not always be set.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1
Use Device Password ID in WSC IE of Probe Request and Probe Response
frames to advertise immediate availability of WPS credentials per P2P
specification sections 3.1.2.1.1 (Listen State), 3.1.2.1.2 (Scan Phase),
and 3.1.2.1.3 (Find Phase).
For now, the Device Password ID is set only for the case where we are
active GO Negotiation with a specific peer. In practice, this means that
the Probe Response frames during pending GO Negotiation (whenever in
Listen state) indicate availability of the credential.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_flush did not explicit stop all P2P operations, i.e., the exact
behavior depended on the P2P module state at the time the p2p_flush
command was issued. Make this more consistent by explicitly calling
p2p_stop_find() from p2p_flush().
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If Listen state was in progress on another channel when a request to
send an Action frame (e.g., Provision Discovery Request or Invitation
Request to a peer on the peer's Listen channel that is different from
our Listenc hannel) is issued, wpa_supplicant tried to use concurrent
remain-on-channel operations. While some drivers can handle this
cleanly, there are drivers that don't and wpa_supplicant is not expected
to request concurrent remain-on-channel operations.
Fix this by cancelling the ongoing remain-on-channel with stop_listen
prior to sending the Action frame on another channel. If a P2P search
was in progress, it will be continued after the timeout on the new
operation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Remove the GPL notification text from files that were initially
contributed by Atheros Communications or Qualcomm Atheros.
Signed-hostap: Jouni Malinen <j@w1.fi>
Search (p2p_scan) could already have been started at the point
remain-on-channel end event is being processed, e.g., if an Action frame
TX is reported immediately aftet the end of an earlier remain-on-channel
operation and the response frame is sent using an offchannel operation
while p2p_find is still in progress. Avoid trying to re-run p2p_scan
while the previous one is still running.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 39185dfa54 changed the p2p_scan()
callback to return 1 in some cases, but forgot to change this p2p_scan()
call to handle that properly. Fix this by processing any non-zero value
as an error. This regression could leave the P2P module in state where
it believed a P2P scan was still running and refused to start some
operations until that scan gets completed (which would never happen
since it was not really started).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
"BSS p2p_dev_addr=<P2P Device Address>" can now be used to fetch a
specific BSS entry based on the P2P Device Address of the GO to avoid
having to iterate through the full BSS table when an external program
needs to figure out whether a specific peer is currently operating as
a GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When the GO negotiation peer is assigned, the state also cannot be IDLE,
SEARCH, or LISTEN_ONLY.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Even though we may not update P2P peer entry while connected to the
peer as a P2P client, we should not be expiring a P2P peer entry while
that peer is the GO in a group where we are connected as a P2P client.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Even though we may not receive a Probe Response from the peer during
the connection, we should not be expiring a P2P peer entry while that
peer is connected to a group where we are the GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This patch notifies the upper framework that an on-going discovery has
been stopped. This is useful in cases where a p2p_find with a timeout
value initiated by the upper framework has been finished or when the
framework initiated "p2p_find" is stopped by a "p2p_connect".
Signed-hostap: Jithu Jance <jithu@broadcom.com>
The Device ID attribute was already used in Listen state, but it was
ignored in GO role. Verify that there is a match with Device ID in
GO rule, too, before replying to the Probe Request frame.
Signed-hostap: Jouni Malinen <j@w1.fi>
dev_id=<P2P Device Addr> can now be specified as an argument to
p2p_find to request P2P find for a specific P2P device.
Signed-hostap: Jouni Malinen <j@w1.fi>
The P2P module provides access to public peer data in struct
p2p_peer_info. Use this to build the P2P_PEER information in
ctrl_iface.c instead of providing such text format data from the P2P
module.
The internal data that was previously built in p2p_get_peer_info() as
part of the text format peer data is now available through a separate
p2p_get_peer_info_txt() function. This is still included in P2P_PEER
output to maintain backwards compatibility with external programs that
could have started to use this. However, it should be noted that this
data is not really supposed to be used for anything else apart from
debugging purposes and its format is subject to change.
Signed-hostap: Jouni Malinen <j@w1.fi>
p2p_get_peer_info() was used in multiple places just to check whether a
specific peer is known. This was not the designed use for the function,
so introduce a simpler function for that purpose to make it obvious that
the p2p_get_peer_info() function is actually used only in ctrl_iface.c.
Signed-hostap: Jouni Malinen <j@w1.fi>
If p2p_listen is issued during a p2p_scan, a pending after-scan operation
is scheduled. However, since there is support for only a single pending
operation, this was able to override a previously scheduled pending
connect command. This can break some command sequences, so give higher
priority to pending connect operation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When waiting for go_neg frame from the peer in WAIT_PEER_CONNECT state,
I have observed that sometimes it takes 20 to 30 secs for successful GO
negotiation. I also found out that it is because of 1 second idle time,
in WAIT_PEER_CONNECT state. While it is good to have 1 second idle time
[for doing power-save or doing some other legacy STA Scan or some other
useful stuff], this makes GO Negotiation process slow.
We wait for 1 second idle and then listen for a random time between
100(min)-300(max) ms. Assume P1 is in WAIT_PEER_CONNECT state and P2 is
the one which is now to send go_neg frame. If P2 sends GO Negotiation
frame just at the boundary of 300 ms of P1 and assume that P2 takes
close to 600-800 ms for one iteration of sending go_neg request (one
iteration is GO Negotiation Request frame time + dwell time +
listen_time), P2 needs to transmit at least 16-18 Action frames for
hitting the listen time of P1.
Following patch reduces the idle time to 500 ms. Alternatively we can
increase the listen time interval to 500 ms just for WAIT_PEER_CONNECT
state.
Provision discovery from a known peer should actually check for
dev->flags & P2P_DEV_PROBE_REQ_ONLY. This is creating an issue of
updating the listen frequency of peer with the PD request frame
frequency. PD request frame will be sent by the peer on our local listen
frequency. This patch fixes that error. Suggested check has already been
implemented in the invitation req receive path.
The Provision Discovery Request needs to be sent on the operating
channel of the GO and as such, the frequency from the BSS table
(scan results) need to override the frequency in the P2P peer
table that could be based on the Listen channel of the GO.
Signed-hostap: Jouni Malinen <j@w1.fi>
The GO negotiation response is very cryptic at the moment. For a success
message we only know on which interface the negotiation succeeded, not
which peer. For a failure we know the interface also and a status code
(number).
It will be very useful for clients to know upon receipt of such a message
which peer the negotiation occurred with.
Now that the peer information is available and the API is changed
already, the function composing the D-Bus message might as well include
all GO negotiation information. This is done with a dict to make things
easier on clients if this result information changes down the line.
Signed-hostap: Reinette Chatre <reinette.chatre@intel.com>
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
When the station is connected to P2P GO after calling p2p_find command
the device sees itself. It is related to lack of filtering itself from
clients connected to P2P GO.
Step by step:
1. dev1: p2p_group_add
2. dev2: p2p_connect <MAC1> pbc join
3. dev1: wps_pbc
4. dev2: p2p_find
Skip P2P client information for our own device from a GO with which
we are connected.
A Pending Provision Discovery Request was sent in SEARCH phase after a
previous provision discovery timeout. Fix this by resetting the config
method of P2P device in the pending PD reset function. This avoids the
sending of a pending Provision Discovery Request during the next P2P
search.
Signed-off-by: Jean-Michel.Bachot <jean-michelx.bachot@intel.com>
Some debug messages used incorrect name for Provision Discovery.
Replace "Provisioning Discovery" with "Provision Discovery".
Signed-hostap: Jouni Malinen <j@w1.fi>
It is safer to assume that the driver could be using NoA and reject
any Presence Request unless we are sure that noa NoA is in use.
Signed-hostap: Jouni Malinen <j@w1.fi>
If Provision Discovery Request is sent for GO role (i.e., P2P Group ID
attribute is included), add the group interface name to the control
interface event on the GO. This makes it easier to figure out which
ctrl_iface needs to be used for wps_pbc/wps_pin command to authorize
the joining P2P client.
Signed-hostap: Jouni Malinen <j@w1.fi>
If p2p_prov_disc join command is used prior to p2p_connect join,
skip the duplicated provision discovery exchange.
Signed-hostap: Jithu Jance <jithu@broadcom.com>
When GO negotation fails the WPS method is currently not cleared, which
can result in GO negotiation being resumed when a GO negotiation request
frame is received from the peer. That is unexpected as locally we
already gave up.
This manifests itself in getting
1319574733.955685: wlan0: P2P-GO-NEG-FAILURE status=-1
1319574733.955723: P2P: Removing pending group interface p2p-wlan0-0
...
1319574736.648378: wlan0: P2P: Starting GO Negotiation with previously
authorized peer
...
1319574736.650115: wlan0: P2P: Sending GO Negotiation Response
...
1319574736.988038: wlan0: P2P-GO-NEG-SUCCESS
1319574736.988233: P2P: No pending group interface
1319574736.988268: P2P: Create a new interface p2p-wlan0-1 for the group
Clear the WPS method to avoid this situation. I wasn't
able to test this though, but given the log I can only
assume this is how the situation happened.
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
If P2P device expires while a GO Negotiation is in progress, currently
p2p->go_neg_peer is cleared without indicating GO Nego failure. This
will result in pending group interfaces to be left over. This patch will
indicate GO Negotiation failure and will remove any pending group
interfaces.
This patch addresses a corner case in GO-Negotiation case. Consider the
scenario where two devices A and B are in discovery stage and Device B
vanishes [moves out of range] when a connect is issued on the Device A.
Then Device A keeps on retrying the GO Negotiation Request till the
retry limit is reached. On reaching retry limit, the pending group
interface is removed. But suppose if the peer entry in the device list
expires before the retry limit is reached, then pending group interface
was not removed.
Signed-off-by: Jithu Jance <jithu@broadcom.com>
Invalid use of memcpy instead of memcmp in comparison resulted in the
GO interface address getting set incorrectly if the GO did not show up
in scan results anymore.
Signed-hostap: Jouni Malinen <j@w1.fi>
If a P2P client associates with the group while it is
already associated, two member entries may be added to
the group which also confuses num_members counting.
Deal with this by removing the existing entry first
before adding a new one.
I think the way Reinette ran into this was due to our
tx_sync implementation in iwlagn, mac80211 might have
queued two association frames thinking the first one
just failed, but both only went out after the sync was
really successful (which tx_sync doesn't wait for).
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
The P2P_FIND command was failing if it was issued at the moment when
a scan operation was in progress. Avoid returning failure in this
case by scheduling the P2P find to start once the ongoing scan is
completed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
For P2P, the p2p_connect takes in device address argument to make a
connection. However the connected event AP-STA-CONNECTED comes with
interface address. The application listening on events would find it
difficult to map interface address to the p2p device address which is
provided for connection.
Append P2P Device Address to AP-STA-CONNECTED event for P2P Client
connection. This will help applications to easily map the P2P Interface
Address to P2P Device Address on CONNECTED event. For non-P2P case, it
will just print the usual STA MAC address alone.
Signed-off-by: Jithu Jance <jithu@broadcom.com>
The persistent_reconnect configuration parameter was used to decide
whether to accept invitation to re-establish a persistent group.
However, this was not being advertised in the Group Capability bitmap.
Add the Persistent Reconnect bit based on this configuration to GO
Negotiation frames and Beacon/Probe Response frames from the GO.
This currently unused function would have triggered wpabuf overflows
due to incorrect variable being reset to zero in the case the old
NoA wpabuf was large enough for the new data.
If GO Negotiation Request (or in theory, also GO Negotiation Response)
frame is delivered multiple time for processing, the SSID of the group
could end up getting changed. This could result in possible issues if
the peer ended up using different SSID. To avoid this, make sure the
SSID does not get changed unless the negotiation is for a new group.
GAS/ANQP is a generic protocol and in no way specific to P2P, so move
routines used to build GAS/ANQP frames to a separate file that can be
shared for other uses than just P2P service discovery.
The new function, p2p_scan_ie_buf_len(), can be used to figure out
how large a buffer needs to be allocated for p2p_scan_ie() use. This
makes it easier to add new data into the buffer without forcing all
callers to be updated to use a larger buffer.
The P2P search mechanism depends on the same scan functionality that
is used for station mode scans. If these operations are being used
at the same time, scan result processing is not handled properly.
Avoid unexpected behavior by delaying station mode scan requests
if a P2P operation is in progress.
Among other things, this allows the station mode connection attempt
to be continued after a P2P find or group formation has been completed
if the interface is available (i.e., when the P2P group uses a
separate virtual interface).
If the initial attempt to start a scan for p2p_find fails, an error
is reported. However, the P2P scan handler and search state was
left behind. That can result in unexpected behavior when the next
non-P2P scan results are indicated. Avoid this by clearing the
P2P search state on failure.
The p2p->drv_in_listen variable is used to track Listen state operations
in the driver. This is cleared when the driver reports that the Listen
state has ended (p2p_listen_end() gets called). However, it is possible
that the driver does not indicate that if the Listen state is canceled.
This can apparently happen in some cases where p2p_connect command is
issues while the Listen state is in progress.
Work around this issue by clearing p2p->drv_in_listen when Listen state
is stopped as part of p2p_stop operation. This allows the P2P module to
process CONNECT_LISTEN timeout in p2p_timeout_connect_listen() to move
to CONNECT state, e.g., when starting GO Negotiation after Device
Discoverability mechanism.
The default config methods was hardcoded to claim support for
PushButton, Display, and Keypad. While these are supported by
most P2P devices, there may be some cases where it is convenient
to be able to disable a specific config method. Use config_methods
configuration parameter to set the default values for Config Methods
in the P2P Device Info attribute.
The P2P specification (3.1.4.3) disallows use of the Label configuration
method between two P2P devices. This was previously enforced at upper
level, but the obsolete code can be removed from wpa_supplicant. This
adds a bit more strict enforcement of the policy, but should not result
in practical differences since no known P2P implementation uses Label
config method.
Commit e1d526293b added code for verifying
whether the receive Probe Request frame was indicating support for only
802.11b rates, but it missed the for loop for the extended supported
rates element. Add that to fix the validation code for cases where
non-802.11b rates are in the extended supported rates element.
Only accept Probe Request frames that have a Wildcard BSSID and a
destination address that matches with our P2P Device Address or is the
broadcast address per P2P specification 3.1.2.1.1.
Fix a bug with the current dev_found()/dev_lost() usage. Previously
in p2p_device_free() dev_lost() was invoked for devices that had
not been dev_found(). This caused dbus related msgs to stderr like:
"Attempted to unregister path (path[0] = fi path[1] = w1) which isn't
registered"
Signed-off-by: Angie Chinchilla <angie.v.chinchilla@intel.com>
Some P2PDevice properties were not updated in p2p->cfg structure:
reg_class, channel, op_reg_class, and op_channel. Hence, update p2p->cfg
parameters through p2p core calls in wpas_p2p_update_config().
Signed-off-by: Jean-Michel.Bachot <jean-michelx.bachot@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Move level parameter from p2p_device to p2p_device_info in order to
expose this information and modify D-Bus P2P handler to return this new
parameter through the P2P device properties.
Signed-off-by: Fabien Marotte <fabienx.marotte@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
When provision discovery fails, this new callback will be called
so P2P users can react to the failure.
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the peer may not be in Listen state when the provision discovery
request is sent, try to send the request again number of times when in
IDLE state. This was already done when p2p_find is in progress, but this
commit adds retries to the case where no other P2P operations are in
progress.
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When building IE from an empty string and CONFIG_WPS_STRICT is
not defined, redundant 2 bytes are being added to the string.
We have to return right after building the "dummy" string.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Store Manufacturer, Model Name, Model Number, and Serial Number
attributes for P2P peers and expose these through the existing
peer information mechanisms.
Make the P2P code keep track of WPS vendor extensions received from
peers so they can be exposed via DBus later.
Signed-off-by: Jean-Michel Bachot <jean-michelx.bachot@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This adds the ability to add WPS vendor extension attributes in P2P
frames, like GO Negotiation and Probe Response frames.
Signed-off-by: Jean-Michel Bachot <jean-michelx.bachot@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add Secondary Device Type List attribute in WSC IE for P2P
Probe Response frames if one or more secondary device types
are configured.
Signed-off-by: Jean-Michel Bachot <jean-michelx.bachot@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will only retrieve information about peers that have been fully
discovered, not peers that are only half-discovered based on their Probe
Request frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The DBus code will want to have perfect matching of dev_found and the
dev_lost it adds so it doesn't need to keep track internally. Enable
that with a new flag in the core that tracks whether we have already
notified about this -- the existing users can ignore it.
The part where this is always set to 1 if the new device is discovered
by a driver that has P2P in the driver is buggy -- the driver should
feed the P2P peer database and then that should feed the notification
here instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This embeds some information about each P2P peer that will be publically
visible in a struct that is shared.
The dev_found notification function is also passed the new struct, which
requires some work for the driver-based P2P management.
Signed-off-by: Konguraj(Raj) Kulanthaivel <konguraj.kulanthaivel@intel.com>
Signed-off-by: Fabien Marotte <fabienx.marotte@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This needs to be done both in the more normal location in
p2p_timeout_connect_listen() (internal timeout after driver event) and
in p2p_listen_end() as a workaround for the case where the driver event
is delayed to happen after the internal timeout.
If the peer you want to connect to is no longer available (does not
acknowledge frames) when wpa_supplicant sends GO Negotition Request
frames, retransmission of this frame is done until the associated
p2p_device structure is removed on timeout. In that case, no signal
is emitted to inform the GO Negotiation has failed.
When sending an Invitation Request frame, the same retransmission
mechanism is in place but limit the transmission to 100 and hitting
the limit generates an event.
This patch adds the same mechanism as the one in place for Invitation
Request, but with limit of 120 to match the existing wait_count for
for GO Negotiation.
Some new code will require access to P2P group members, so add API to
retrieve the number of members and iterate the members themselves.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If there is a pending GO Negotiation when p2p_cancel is used,
unauthorize the peer to avoid immediate reconnection from being
accepted without a new p2p_connect command.
When the peer does not include our initial preference in the Channel
List attribute during GO Negotiation, try to use the best channel of
the other band as the new preference instead of falling back to the
first channel in the intersection.
The driver wrapper may now indicate the preferred channel (e.g., based
on scan results) on both 2.4 GHz and 5 GHz bands (and an overall best
frequency). When setting up a GO, this preference information is used
to select the operating channel if configuration does not include
hardcoded channel. Similarly, this information can be used during
GO Negotiation to indicate preference for a specific channel based
on current channel conditions.
p2p_group_add command can now use special values (freq=2 and freq=5)
to indicate that the GO is to be started on the specified band.
We need to drop the pending frame to avoid issues with the new GO
Negotiation, e.g., when the pending frame was from a previous attempt at
starting a GO Negotiation.
We are not actually interested in the PD Response in join-a-group
case, so there is no point in trying to send PD Request until the
response is received. This avoids an extra PD getting started after
a join-a-group operation in some cases.
A new configuration parameter, p2p_group_idle, can now be used to set
idle timeout value for P2P groups in seconds (0 = no timeout). If set,
this values is used to remove P2P group (both GO and P2P client)
interfaces after the group has been idle (no clients/GO seen) for the
configuration duration.
The P2P-GROUP-REMOVED event is now indicating the reason for group
removal when known. For example:
P2P-GROUP-REMOVED wlan0 GO reason=REQUESTED
P2P-GROUP-REMOVED wlan1 client reason=IDLE
In order to avoid confusing the driver with a new remain-on-channel
request, delay sending of a new Action frame if the driver indicates
Action frame RX diromg a scan.
This is needed to optimize response to GO Negotiation Request frames.
The extra remain-on-channel cancel followed by new remain-on-channel for
the same channel takes too much time with some driver/firmware
designs for the response to go out quickly enough to avoid peer
timing out while waiting for our response.
The P2P group component is now tracking of associated stations
in the group and the Group Limit bit in the Group Capabilities
is updated based on whether there is room for new clients in
the group.
The workaround to ignore no ctrl::ack received for GO Negotiation
Confirmation frame was only supposed to be used when the frame was
actually transmitted and just the ack was not received. However, due
to the way the driver failure on transmitting the frame were reported,
this ended up getting applied for all failures in sending the GO
Negotiation Confirmation frame.
Improve this by providing a mechanism to indicate whether send_action
operations fail locally before the frame was actually transmitted or
because of not receiving ack frame after having transmitted the frame.
The driver wrapper can now indicate whether the driver supports
concurrent operations on multiple channels (e.g., infra STA connection
on 5 GHz channel 36 and P2P group on 2.4 GHz channel 1). If not,
P2P_CONNECT commands will be rejected if they would require
multi-channel concurrency.
The new failure codes for P2P_CONNECT:
FAIL-CHANNEL-UNAVAILABLE:
The requested/needed channel is not currently available (i.e., user has
an option of disconnecting another interface to make the channel
available).
FAIL-CHANNEL-UNSUPPORTED:
The request channel is not available for P2P.
If the peer is not authorized for GO Negotiation, wps_method is not
actually set. In that case, it is better to fill in our default
config methods rather than end up leaving the field to be zero.
If the msg->device_name buffer is filled from two different sources,
the copy from the P2P Device Info attribute needs to make sure that
the values gets null terminated to match the length of the correct
string should the other place use another string (which is not really
allowed by the spec, but could happen).
If an authorized (p2p_connect used locally) GO Negotiation is
rejected when receiving GO Negotiation Request from the peer,
indicate the failure with a ctrl_interface P2P-GO-NEG-FAILURE
event. Previously, this event was only shown on the peer (i.e.,
the device receiving the GO Negotiation Response with non-zero
Status code).
Since this message now includes P2P Device Info attribute, it is
reasonable to learn the peer data and process the message instead of
rejecting the message.
Add (or complete Probe Request only) P2P peer entry when receiving
Provision Discovery Request from a previously unknown peer. This is
especially of use for a GO when a P2P client is requesting to join
a running group.
The scan operation before Provision Discovery Request may not include
the GO. However, we are likely to have the GO in our P2P peer table,
so use that information to figure out the operating channel if BSS
table entry is not available.
This should not really happen, but it looks like the Listen command
may fail is something else (e.g., a scan) was running at an
inconvenient time. As a workaround, allow new Extended Listen
operation to be started if this state is detected.
The previous version had a bug that could result in NULL pointer
dereference if the P2P IE included Manageability attribute, but no
Capability attribute.
This can happen, e.g., when a P2P client connects to a P2P group
using the infrastructure WLAN interface instead of P2P group
interface. In that case, the P2P client may behave as if the GO
would be a P2P Manager WLAN AP.
P2P specification v1.15 fixed the description of the GAS fragmentation
to not duplicate NQP Query Response Field header in all fragments. This
change makes the fragmentation match with the description in IEEE
802.11u. The change is not backwards compatible with previous P2P
specification versions as far as fragmented SD responses are concerned.
This event indicates the Device Password ID that the peer tried
to use in GO Negotiation. For example:
P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7 dev_passwd_id=4
If enabled, cross connection allows GO to forward IPv4 packets
using masquerading NAT from the P2P clients in the group to an
uplink WLAN connection. This is disabled by default and can be
enabled with "wpa_cli p2p_set cross_connect 1" on the P2P device
interface.
When we receive Device Discoverability Response, we need to initiate
new GO Negotiation as quickly as possible to avoid the target client
from going back to sleep. Make sure we do not end up in
P2P_CONNECT_LISTEN state (short Listen mode) in this case.
While this is not strictly speaking required by the P2P specification
for a not-P2P Managed Device, this can provide useful information for
the P2P manager AP and may be needed to pass certification tests.
While there is no real value in this, the spec seems to mark this
attribute as mandatory from GO, so better included it regardless
of whether we have clients or not (the attribute is empty in case
no clients are connected).
"wpa_cli p2p_set peer_filter <MAC address>" can now be used to
only allow a single P2P Device (based on P2P Device Address) to be
discovered for testing. Setting the address to 00:00:00:00:00:00
disables the filter.
