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.
Some debug messages used incorrect name for Provision Discovery.
Replace "Provisioning Discovery" with "Provision Discovery".
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>
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>
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 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 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>
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>
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.
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.
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.
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 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.
