When controlling multiple virtual interfaces on the same physical
radio, share the scan results events with sibling interfaces. This
decreases the time it takes to connect many virtual interfaces.
This is currently only supported on Linux with cfg80211-based
drivers when using nl80211 or wext driver interface.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Some drivers are not providing exactly reliable error codes (e.g.,
with WEXT), but others may actually indicate reliable information.
Allow driver wrappers to indicate if that is the case and use
optimizations if so. For now, this improves nl80211 with
NL80211_CMD_CONNECT for a case where connection request fails.
mac80211 can indicate this mainly because of channel selection
conflicts with other vifs. If there is another BSS on another
channel, we should try to connect to it instead.
WPA_DRIVER_FLAGS_P2P_MGMT_AND_NON_P2P flag can now be used to
indicate that the initial interface (e.g., wlan0) is used for
P2P management operations and potentially non-P2P connections.
This is otherwise identical to
WPA_DRIVER_FLAGS_P2P_DEDICATED_INTERFACE, but the possibility of
non-P2P connections makes some operations differ.
This may make it less likely for udev to rename the interface that
would previously have been called wlan0-p2p-# (now: p2p-wlan0-#).
In addition, add some workaround code to handle the case where the
main interface name is close to the IFNAMSIZ length limit to
avoid going over that for the P2P group interface.
In theory, the interface name could be longer than IFNAMSIZ in
some systems, so use the same size buffer for this field as is
used with the main interface name.
Some other dnsmasq users (like libvirt) seem to be binding the DHCP
server to all interfaces which prevents the previously used mechanism
here from working (bind on the DHCP socket fails). If a failure is
noticed, try to start dnsmasq with -z option to avoid that.
Move the previously SME specific optimization code into generic
function that can be used from non-SME code, too, and use it to
handle disconnection events. In other words, allow disconnection
event to trigger similar optimized scanning case to handle a
common load balancing mechanism. If there is another BSS in the
same ESS when we receive a disconnection event, scan only the
known frequencies of such other BSSes on the next attempt to
speed up recovery.
The special case of requiring blacklisting count to be 2 or higher
is only needed when more than a single network is currently enabled.
As such, we should not do that when only a single network is enabled.
This make the station more likely to follow network side load
balancing attempts where the current AP may disassociate us with
an assumption that we would move to another AP.
When authentication or association fails when trying to connect to
a BSS in an ESS that has multiple BSSes based on previous scans,
limit the first recovery scan to only the known channels that has
been seen previously. This speeds up recovery in some of the most
commonly used load balancing mechanisms in enterprise WLAN
networks.
There were various issues in how the SME (i.e., nl80211-based driver
interface) handled various authentication and association timeouts and
failures. Authentication failure was not handled at all (wpa_supplicant
just stopped trying to connect completely), authentication timeout
resulted in blacklisting not working in the expected way (i.e., the same
BSS could be selected continuously), and association cases had similar
problems.
Use a common function to handle all these cases and fix the blacklist
operation. Use smaller delay before trying to scan again during the
initial cycle through the available APs to speed up connection. Add
a special case for another-BSS-in-the-same-ESS being present to
speed up recovery from networks with multiple APs doing load balancing
in various odd ways that are deployed out there.
assoc_freq needs to be cleared when an interface gets disconnected.
This fixes an issue where P2P Action frame transmission may fail
because of missing remain-on-channel operation when using the same
interface for group operations (or non-P2P connections) and P2P
management operations.
The wpa_supplicant_event() EVENT_TX_STATUS ack field needs to be
converted to use wpas_send_action_tx_status()
enum p2p_send_action_result in this case, too, to avoid getting
incorrect TX status for P2P processing.
By default, make hostapd and wpa_supplicant maintain an internal
entropy pool that is fed with following information:
hostapd:
- Probe Request frames (timing, RSSI)
- Association events (timing)
- SNonce from Supplicants
wpa_supplicant:
- Scan results (timing, signal/noise)
- Association events (timing)
The internal pool is used to augment the random numbers generated
with the OS mechanism (os_get_random()). While the internal
implementation is not expected to be very strong due to limited
amount of generic (non-platform specific) information to feed the
pool, this may strengthen key derivation on some devices that are
not configured to provide strong random numbers through
os_get_random() (e.g., /dev/urandom on Linux/BSD).
This new mechanism is not supposed to replace proper OS provided
random number generation mechanism. The OS mechanism needs to be
initialized properly (e.g., hw random number generator,
maintaining entropy pool over reboots, etc.) for any of the
security assumptions to hold.
If the os_get_random() is known to provide strong ramdom data (e.g., on
Linux/BSD, the board in question is known to have reliable source of
random data from /dev/urandom), the internal hostapd random pool can be
disabled. This will save some in binary size and CPU use. However, this
should only be considered for builds that are known to be used on
devices that meet the requirements described above. The internal pool
is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
We can automatically accept invitations that are for a persistent
group that is already running. There is no need to confirm this
separately or preparare a new group interface.
When an Invitation to reinvoke a persistent group is accepted,
we need to make sure that any pending p2p_find or p2p_listen
operation gets stopped to avoid consuming all radio resources
doing device discovery while the group is being set up.
The duplicated WPS event in the parent interface should only be used
during P2P group formation, i.e., when the WPS operation was actually
started using the parent interface. When authorizing a client to
connect to an already running group, the WPS command is issued on
the group interface and there is no need to duplicate the event to
the parent interface.
This pointer is now used in number of places to check whether an
interface is in P2P Group Formation, so we better make sure it gets
cleared when group formation has been completed. This was done in
only some of the cases.
ap_setup_locked=2 can now be used to enable a special mode where
WPS ER can learn the current AP settings, but cannot change then.
In other words, the protocol is allowed to continue past M2, but
is stopped at M7 when AP is in this mode. WPS IE does not
advertise AP Setup Locked in this case to avoid interoperability
issues.
In wpa_supplicant, use ap_setup_locked=2 by default. Since the AP PIN
is disabled by default, this does not enable any new functionality
automatically. To allow the read-only ER to go through the protocol,
wps_ap_pin command needs to be used to enable the AP PIN.
The pending_invite_ssid_id of -1 (running group, not persistent) was
being stored incorrectly in the group interface, not device interface
(i.e., parent of the group interface) and consequently, the incorrect
information was used when processing the Invitation Response.
If there was a persistent group credentials stored with network id
0, those were used instead to try to set up a persistent group
instead of using the already running group.
Since the P2P peer entry may not have been available at the time the
join request was issued, we need to allow the P2P Interface Address
to be updated during join-scans when the P2P peer entry for the GO
may be added.
If the GO is not found, we cannot send Provisioning Discovery Request
frame and cannot really connect anyway. Since the Provisioning
Discovery is a mandatory part, it is better to continue join-scan
until the GO is found instead of moving to the next step where
normal connection scan is used (PD would not be used from there).
Use a limit of 10 scan attempts for p2p_connect join to avoid getting
in infinite loop trying to join. If the GO is not found with those
scans, indicate failure (P2P-GROUP-FORMATION-FAILURE) and stop the
join attempt.
CONFIG_WPA_CLI_EDIT=y can now be used to build wpa_cli with internal
implementation of line editing and history support. This can be used
as a replacement for CONFIG_READLINE=y.
Instead of using a separate process to receive and print event
messages, use a single-process design with eloop to simply
wpa_cli and interaction with readline.
Instead of multiple #ifdef blocks for readline within the function,
use two copies of the functions, one for readline, one without any
readline functionality.
When running "p2p_connect addr pbc join" command, send the
WPS-OVERLAP-DETECTED even also to the parent interface (i.e.,
the one on which the p2p_connect was issued) and not only the
group interface in case separate P2P group interfaces are used.
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.
wpa_supplicant_set_driver() is returning an error if the first driver
in the driver list is not built in. It should continue through the
driver list until it finds one that's built in.
If IEE8021X_EAPOL is not enabled in the config, wpa_drv_set_supp_port
must be called from the supplicant, otherwise port will not be
activated after association.
Commit d8d940b746 introduced a regression
that prevented TSN APs from being used with WEP since the AP was
rejected if it advertised WPA or RSN IE when we were configured to use
WEP. Resolve this by checking whether the AP is advertising a TSN, i.e.,
whether the AP allows WEP to be used as a group cipher. If so, allow
the AP to be selected if we are configured to use static WEP or
IEEE 802.1X (non-WPA).
It should be noted that this is still somewhat more restricted in AP
selection than earlier wpa_supplicant branches (0.7.x or older) that
ignore the WPA/RSN IE completely when configured for non-WPA.
The driver may end up leaving the current channel when we request
a new remain-on-channel and as such, it is better not assume we can
start new operations like sending an Action frame on the previous
off-channel.
If we have already asked the driver to start a new remain-on-channel,
we need to cancel it even if the actual remain-on-channel has not yet
started at the point when a new operation or timeout etc. triggers
Listen state to be stopped.
Even if p2p_scan_res_handler() returns 1 to indicate that scan result
iteration should be stopped, the p2p_scan_res_handled() needs to be
called to clear p2p_scan_running and to get a callback that will start
any operations that were delayed because of the running scan.
There is no need to separately move to the correct channel
for transmitting an Action frame that is using the group
interface (i.e., source address is P2P Interface Address).
This removes extra latency from P2P Action frame operations
within a P2P group.
This is an option to continue with wpa_supplicant and hostapd even if
config file has errors. The problem is that these daemons are the best
"candidates" for the config change, so if they can not start because
config file was let's say corrupted, you can not fix it easily.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
This could have been using an uninitialized variable instead of
purposefully random value in picking up the channel. There is not
much of a difference for the use case here, but anyway, we may
as well do what was initially planned here and.
The destination address for p2p_serv_disc_resp must always be set
to an individual MAC address unlike p2p_serv_disc_req which may use
00:00:00:00:00:00 to indicate wildcard query. As such, we should not
try to check for this special case here.
The ieee80211_sta_free_hw_features() function is now used outside
the MLME code, so better make sure it gets included in the build
to avoid leaking memory.
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
Replacing the BSSID with 'any' has never worked with wps_reg
command, so better not claim it could work. In addition, reject
this is wpa_supplicant to make it clearer that the operation
fails.
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
The driver wrapper may indicate EVENT_CHANNEL_LIST_CHANGED before
completing init(). This would likely result in segfault when driver
channel list is being read as part of processing this event when
P2P is enabled.
This command can be used to enroll a network based on a local
network configuration block instead of having to (re-)learn the
current AP settings with wps_er_learn.
This is not supposed to happen, but in theory, the GO may end up
changing its channels at some point. While it would be reasonable
to use one of the common channels, GO may be forced to use another
channel. The most likely reason for this would be if the P2P client
is enforcing only a single channel to be used (e.g., to avoid
multi-channel concurrent operations).
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.
This driver capability limit was supposed to indicate limit on
how many stations can associate with us in the AP mode, not how
many P2P peers are stored in the peer table.
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.
This is needed to work around cases where the pending interface gets
removed, e.g., due to failed GO Negotiation. In such case, we may still
accept new GO Negotiation to be completed, but the interface did not
get created without a separate p2p_connect command.
The current implementation is not ideal since the re-created interface
may, at least in theory, get incorrect interface addrees. Though, this
would likely require that the driver supported more than one P2P group
interface and that the previous one was already taken into use for
another group.
This is a workaround for incorrect configuration (missing
virtual/physical identifier for config methods) for WPS 2.0 to
allow unmodified configuration from WPS 1.0 to be used while
enforcing compliant WPS 2.0 values.
The AP operation with wpa_supplicant requires an additional callback
to get the needed event information from hostapd side so that
wpa_msg() can be called for wpa_s->parent if needed.
This makes it easier to figure out what could have failed in the
WPS protocol and potentially provide more information for the
user on how to resolve the issue.
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.
Allow only the expected P2P Interface Address as the BSSID for
the AP to avoid selecting incorrect BSS should there be another
device that is advertising active PBC mode before the target
P2P GO does.
When the P2P state machine requests a remain- on-channel, there's a
potential race where it can then request a stop before the r-o-c has
actually started, in which case the stop will not be processed. Fix
that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The new DBus API helper function wpas_dbus_error_unknown_error
function can be called as a result of a failure within internal
getter calls, which will call this function with a NULL message
parameter. However, dbus_message_new_error looks very unkindly
(i.e, abort()) on a NULL message, so in this case, we should not
call it.
I've observed this course of events during a call to
wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
We got here through a call to fill_dict_with_properties which
explicitly calls getters with a NULL message parameter. Judging
from the way it is called, this could easily occur if an AP sends
out a malformed (or mis-received) probe response. I usually run
into this problem while driving through San Francisco, so I'm
exposed to any number of base stations along this path.
This patch changes wpa_supplicant policy for handling '' in SSIDs field of
Interface.SSID DBus message. It treats '' (zero-length) SSID as a request
for a broadcast scan, instead of ignoring it.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: 1 broadcast ProbeRequest on specified channel
2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; passive scan results for specified channel
This Patch: FIXED: 1 broadcast ProbeRequest on specified channel
3) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['MySSID']})
Request: Active scan with only non-'' SSIDs (1 channel)
Should be: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
Previous: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
This Patch: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['',
'MySSID']})
Request: Active scan with SSIDs, including 1 '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest, 1 directed ProbeRequest for each
non-'' SSID on specified channel
Previous: 1 directed ProbeRequest for each non-'' SSID on specified
channel
This Patch: FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest for
each non-'' SSID on specified channel
Currently the DBus Interface.Scan API is counter-intuitive. It issues
ProbeRequests when doing passive scans when channels are specified, and
does not issue ProbeRequests for broadcast active scans.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'passive'})
Request: Passive scan (all channels)
Should be: No ProbeRequests; Passive Scan results for all channels
Previous: 1 ProbeRequest on all channels for both broadcast SSID and
selected network (scan_ssid=1)
This Patch: --No change--: 1 ProbeRequest on all channels for both
broadcast SSID and selected network (scan_ssid=1)
2) Interface.Scan({'Type':'passive', 'Channel':(2412, 20)})
Request: Passive scan (1 channel)
Should be: No ProbeRequests; Passive Scan results for 1 channel
(plus overlapping channels)
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: --Fixed--: No ProbeRequests; Passive Scan results for 1
channel (plus overlapping channels)
3) Interface.Scan({'Type':'active'})
Request: Active scan with no SSIDs (all channels)
Should be: 1 broadcast ProbeRequest on all channels
Previous: No ProbeRequests; passive scan results for all channels
This Patch: --Fixed--: 1 broadcast ProbeRequest on all channels
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with no SSIDs (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; Passive scan results for specified
channel (plus overlapping channels)
This Patch: --Fixed--: 1 broadcast ProbeRequest on specified channel
The previous used .gitignore files were mathing some files that
were actually already in the repository (e.g.,
hostapd/logwatch/hostapd). Avoid this by listing the conflicting
entries in the root directory .gitignore with full path.
