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>
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>
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>
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>
Remove the GPL notification text from files that were initially
contributed by Atheros Communications or Qualcomm Atheros.
Signed-hostap: Jouni Malinen <j@w1.fi>
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.
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.
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.
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>
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.
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.
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.
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).
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.
Jouni Malinen