The signal strength is currently never used as the only driver reporting
it is nl80211 which uses IEEE80211_RADIOTAP_DB_ANTSIGNAL which is never
populated by the kernel. The kernel will (soon) populate
IEEE80211_RADIOTAP_DBM_ANTSIGNAL instead though, so use that.
Also, since it was never really populated, we can redefine the signal
field to be in dBm units only.
My next patch will also require knowing the signal strength of probe
requests throughout the code (where available), so add it to the
necessary APIs.
Signed-hostap: Johannes Berg <johannes.berg@intel.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>
When a GO is operating a persistent group and invites a peer that has
been a P2P client in that persistent group, the Invitation Type in the
Invitation Request frame can be set to 1 to indicate that this is a
reinvocation of a persistent group. Do this based on the maintained
list of P2P clients that have been provided the credentials to this
group.
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>
Add a new persistent group network block field, p2p_client_list, to
maintain a list of P2P Clients that have connected to a persistent
group. This allows GO of a persistent group to figure out more easily
whether re-invocation of a persistent group can be used with a specific
peer device.
Signed-hostap: Jouni Malinen <j@w1.fi>
Add "persistent=<network id>" line to P2P_PEER ctrl_iface data
if a persistent group credentials are available for this peer.
This makes it easier for external programs to figure out when
a persistent group could be re-invoked with this peer.
For now, this information is only available on the P2P client,
but similar information can be added for GO once a list of P2P
clients is maintained with the persistent group data.
Signed-hostap: Jouni Malinen <j@w1.fi>
Convert core wpa_supplicant code to use u64 instead of void * for the
P2P service discovery reference. Use uintptr_t in type casts in
p2p_supplicant.c to handle the conversion without warnings.
Note: This needs to be revisited for 128-bit CPU where sizeof(void *)
could be larger than sizeof(u64).
Signed-hostap: Jouni Malinen <j@w1.fi>
If a P2P group network block is removed for any reason (e.g., wps_cancel
command) while the interface is in group formation, remove the group
formation timeout and indicate failure immediately. Previously, this
type of operations could end up leaving the timeout running and result
in somewhat unexpected group formation failure events later.
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>
This can be used to request Provision Discovery Request to be sent
for the purpose of joining a running group, e.g., to request the GO
to display a PIN that we can then use with p2p_connect join command.
Signed-hostap: Jithu Jance <jithu@broadcom.com>
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).
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.
Signal is triggered if an error occurs during WPS provisioning phase.
Signed-off-by: Jean-Michel.Bachot <jean-michelx.bachot@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@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>
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.
Add a new driver event, EVENT_INTERFACE_UNAVAILABLE, for indicating
that the driver is not able to continue operating the virtual
interface in its current mode anymore, e.g., due to operating
channel for GO interface forced to a DFS channel by another virtual
interface.
When this happens for a P2P group interface, the P2P group will
be terminated and P2P-GROUP-REMOVED event shows the reason for
this as follows:
P2P-GROUP-REMOVED wlan0 GO reason=UNAVAILABLE
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 overlap condition cannot disappear before group formation timeout
hits, so there is no point in continuing in this case and failure can
be indicated immediately.
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.
For now, this applies to the test command that can be used to set
periodic NoA (p2p_set noa). The value are stored and periodic NoA
is enabled whenever there are no non-P2P STAs connected to the GO.
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.
