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>
