This function is always called with the peer argument equal to
p2p->go_neg_peer, so there is no need for that argument to be there. In
addition, p2p->go_neg_peer is not NULL in cases where there is an
ongoing GO Negotiation, so the function can be simplified to just check
once whether the peer pointer is set and if not, skip all processing.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The timeout check while waiting for the peer to accept the GO
Negotiation depended on the WAIT_PEER_IDLE or WAIT_PEER_CONNECT states
being in use. Any P2P command to alter such states would have resulted
in the failure to time out GO Negotiation and thus ended up in not
indicating GO Negotiation failure or left the selected peer available
for new GO negotiation after the expected two minute timeout.
Fix this by using a separate timer to time out GO Negotiation
irrespective of the P2P state.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If a TX status event and RX event for a GO Negotiation frame gets
delayed long enough to miss the initial wait, it was possible for
reception of a GO Negotiation Response frame with status 1 to try to
initiate a new p2p-listen work item to wait for the peer to become ready
while a previous p2p-listen was already in progress due to that earlier
timeout while waiting for peer. This would result in the new
start_listen request getting rejected ("P2P: Reject start_listen since
p2p_listen_work already exists") and the negotiation not proceeding.
Work around this by using P2P_WAIT_PEER_CONNECT state instead of
P2P_WAIT_PEER_IDLE if P2P_CONNECT_LISTEN state has already been entered
when processing this special GO Negotiation Response status=1 case. This
can avoid double-scheduling of p2p-listen and as such, completion of the
GO negotiation even if the driver event or peer response are not
received in time (the response is supposed to be there within 100 ms per
spec, but there are number of deployed devices that do not really meet
this requirement).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds following new control interface commands to allow arbitrary
vendor elements to be added into number of frames:
VENDOR_ELEM_ADD <frame id> <hexdump of elem(s)>
VENDOR_ELEM_GET <frame id>
VENDOR_ELEM_REMOVE <frame id> <hexdump of elem(s)>
VENDOR_ELEM_REMOVE <frame id> *
The following frames are supported in this commit (additional frames can
be added in the future):
0 = Probe Request frame in P2P device discovery
1 = Probe Response frame from P2P Device role
2 = Probe Response frame from P2P GO
3 = Beacon frame from P2P GO
4 = PD Req
5 = PD Resp
6 = GO Neg Req
7 = GO Neg Resp
8 = GO Neg Conf
9 = Invitation Request
10 = Invitation Response
11 = P2P Association Request
12 = P2P Association Response
One or more vendor element can be added/removed with the commands. The
hexdump of the element(s) needs to contain the full element (id, len,
payload) and the buffer needs to pass IE parsing requirements to be
accepted.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Peer should handle a GO Negotiation exchange correctly when the
responding device does not have WSC credentials available at the
time of receiving the GO Negotiation Request. WSC Credentials
(e.g., Pushbutton) can be entered within the 120 second timeout.
Presently, if concurrent session is not active, the peer would wait for
GO Negotiation Request frame from the other device for approximately one
minute due to the earlier optimization change in commit
a2d6365760. To meet the two minute
requirement, replace this design based on number of iterations with a
more appropriate wait for the required number of seconds.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
wpa_supplicant now retries for P2P_GO_NEG_CNF_MAX_RETRY_COUNT times if
it doesn't receive acknowledgement for GO Negotiation Confirmation
frame. Currently, P2P_GO_NEG_CNF_MAX_RETRY_COUNT is set to 1.
While this is not strictly speaking following the P2P specification,
this can improve robustness of GO Negotiation in environments with
interference and also with peer devices that do not behave properly
(e.g., by not remaining awake on the negotiation channel through the
full GO Negotiation).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
p2p_find removes P2P_DEV_REPORTED flag from every existing P2P peer
entry. Thus, if a GO Negotiation Request frame is received before the
peer is re-discovered based on Probe Response frame, report
P2P-DEVICE-FOUND indication prior to the P2P-GO-NEG-REQUEST similarly to
how this is done the first time the peer is found.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The mechanism of using Status attribute in GO Negotiation Request was
used in some early specification drafts, but it is not compliant with
the current P2P specification where GO Negotiation Request is used only
for the purpose of initiating a new GO Negotiation. However, some
deployed devices use it to indicate rejection of GO Negotiation in a
case where they have sent out GO Negotiation Response with status 1. The
P2P specification explicitly disallows this.
To avoid unnecessary interoperability issues and extra frames, mark the
pending negotiation as failed and do not reply to this GO Negotiation
Request frame. Previously, GO Negotiation Response frame with status=4
was sent back as an indication of the GO Negotiation Request frame being
invalid. This response is not sent anymore and the status code for the
P2P-GO-NEG-FAILURE event is changed from 4 (invalid parameters) to 11
(rejected by user) for this specific workaround case.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
1. In wpa_config_process_bgscan() fix memory leak after
calling wpa_config_parse_string()
2. In hostapd_config_defaults(), on failure to allocate bss->radius,
conf->bss was not freed.
3. In p2p_deauth_nofif(), memory allocated in p2p_parse_ies() was not
freed in case of NULL minor_reason_code.
4. In p2p_disassoc_nofif(), memory allocated in p2p_parse_ies() was
not freed in case of NULL minor_reason_code.
5. In p2p_process_go_neg_conf(), memory allocated was not freed in
case that the P2P Device interface was not waiting for a
GO Negotiation Confirm.
6. In wpa_set_pkcs11_engine_and_module_path(), the wrong pointer was
checked.
Signed-hostap: Eytan Lifshitz <eytan.lifshitz@intel.com>
"NFC_REPORT_HANDOVER {INIT,RESP} P2P <req> <sel>" can now be used to
report completed NFC negotiated connection handover in which the P2P
alternative carrier was selected.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, GO Negotiation Request frame was used to update a peer entry
if only a Probe Request from that peer had been received. However, it
would be possible, even if unlikely, for a peer to be discovered based
on receiving Provision Discovery Request frame from it and no Probe
Request frame. In such a case, the Listen frequency of the peer would
not be known and group formation could not be (re-)initialized with that
peer. Fix this by allowing the GO Negotiation Request frame to update
peer entry if the current peer entry does not include Listen or
Operating frequency.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This reverts commit 792c8877c3
('P2P: Send GO Negotiation Confirm without wait').
Some drivers rely on the wait period for sending packets on the
off-channel. If the wait value is small, there's a race condition where
the driver ROC might complete before the packet was sent out. This
doesn't impede other drivers, as the wait is cancelled when a
Tx-completion arrives from the remote peer.
Signed-hostap: Arik Nemtsov <arik@wizery.com>
The missing call to scan_action_done() may keep us off-channel for 250
ms following sending GO Negotiation Response. In case the operating
channel is different from this channel and we're GO, a race could lead
to start beaconing while off-channel. This could potentially cause the
Beacon frames to go out on incorrect channel with some drivers.
Signed-hostap: Eyal Shapira <eyal@wizery.com>
Some devices disable use of U-NII-1 (channels 36-48) for P2P due to it
being indoor use only in number of locations. If U-NII-3 (channels
149-161) is available, try to pick a channel from that range first
during random channel selection to reduce likelihood of interoperability
issues.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Use the new p2p_channel_select() function to select a VHT channel
at random when no other preferences are in effect.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Use the new p2p_channel_select() function to select an HT40 channel
at random when no other preferences are in effect.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The new p2p_channel_select() function can be re-used to implement
random channel selection from a set of operating classes in all
places that need such functonality.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Start GO with VHT support if VHT option was requested
and the appropriate channels are available.
Signed-hostap: Eliad Peller <eliadx.peller@intel.com>
The new p2p_add_cli_chan=1 configuration parameter can be used to
request passive-scan channels to be included in P2P channel lists for
cases where the local end may become the P2P client in a group. This
allows more options for the peer to use channels, e.g., if the local
device is not aware of its current location and has marked most channels
to require passive scanning.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The new p2p_no_go_freq frequency range list (comma-separated list of
min-max frequency ranges in MHz) can now be used to configure channels
on which the local device is not allowed to operate as a GO, but on
which that device can be a P2P Client. These channels are left in the
P2P Channel List in GO Negotiation to allow the peer device to select
one of the channels for the cases where the peer becomes the GO. The
local end will remove these channels from consideration if it becomes
the GO.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Even though the length of this buffer is based only on locally
configured information, it is cleaner to include explicit buffer room
validation steps when adding the attributes into the buffer.
Signed-hostap: Jouni Malinen <j@w1.fi>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
