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.
