This allows background scanning and roaming decisions to be contained in
a single place based on a defined set of notification events which will
hopefully make it easier to experiment with roaming improvements. In
addition, this allows multiple intra-ESS roaming policies to be used
(each network configuration block can configure its own bgscan module).
The beacon loss and signal strength notifications are implemented for
the bgscan API, but the actual events are not yet available from the
driver.
The included sample bgscan module ("simple") is an example of what can
be done with the new bgscan mechanism. It requests periodic background
scans when the device remains associated with an ESS and has couple of
notes on what a more advanced bgscan module could do to optimize
background scanning and roaming. The periodic scans will cause the scan
result handler to pick a better AP if one becomes available. This bgscan
module can be taken into use by adding bgscan="simple" (or
bgscan="simple:<bgscan interval in seconds>") into the network
configuration block.
After transitioning from DISCONNECTED to SCANNING, we never go back
to DISCONNECTED even though scanning is done or failed.
We're thus stuck in SCANNING while scanning is actually done.
This introduces a new mechanism for collecting notification calls into
a single place (notify.c). As a result of this, most of the
wpa_supplicant code does not need to know about dbus (etc. mechanisms
that could use the notifications). Some empty placeholder functions are
also added in preparation of new dbus code that needs more event
notifications.
When the supplicant is connected and performs a scan, it doesn't enter
WPA_SCANNING state for various reasons. However, external programs
still need to know that the supplicant is scanning since they may not
wish to perform certain operations during a scan (as those operations
will likely fail or yield incorrect results). Add a 'scanning' property
and signal to the supplicant dbus interface to allow clients to
synchronize better with the supplicant when it scans.
Signed-off-by: Dan Williams <dcbw@redhat.com>
A new network block parameter, scan_freq, can be used to specify subset
of frequencies to scan. This can speed up scanning process considerably
if it is known that only a small subset of channels is actually used in
the network. A union of configured frequencies for all enabled network
blocks is used in scan requests.
Currently, only driver_nl80211.c has support for this functionality.
For example, following parameter marks 2.4 GHz channels 1, 6, 11 to be
scanned: scan_freq=2412 2437 2462
wpa_supplicant can now initialize hostapd data structures when mode=2 is
used to set up an AP. The hostapd configuration is not yet set based on
wpa_supplicant network configuration block. In addition, the glue code
for hostapd driver_ops needs number of functions that will be needed for
AP functionality.
This can be used, e.g., with mac80211-based Linux drivers with
nl80211. This allows over-the-air FT protocol to be used (IEEE
802.11r).
Since the nl80211 interface needed for this is very recent (added
today into wireless-testing.git), driver_nl80211.c has backwards
compatibility code that uses WEXT for association if the kernel does
not support the new commands. This compatibility code can be
disabled by defining NO_WEXT_COMPAT. That code will also be removed
at some point to clean up driver_nl80211.c.
Do not use just the driver name for this since driver_ndis.c supports
both wired and wireless NDIS drivers and needs to indicate the driver
type after initialization.
If the driver reports support for more than one SSID per scan request,
optimize scan_ssid=1 operations in ap_scan=1 mode. This speeds up
scanning whenever scan_ssid=1 is used since the broadcast SSID can be
included in every scan request and if driver supports more than two
SSIDs in the scan request, the benefits are even larger when multiple
networks have been configured with ap_scan=1.
This is also cleaning up wpa_supplicant_scan() function by moving code
around so that the SSID list is not processed unnecessarily if the
operation mode does not need this.
This can be used to provide support for scanning multiple SSIDs at a
time to optimize scan_ssid=1 operations. In addition, Probe Request IEs
will be available to scan2() (e.g., for WPS PBC scanning).
Some WPS APs do not set Selected Registrar attribute to 1 properly when
using an external Registrar. Allow such an AP to be selected for PIN
registration after couple of scan runs that do not find APs marked with
Selected Registrar = 1. This allows wpa_supplicant to iterate through
all APs that advertise WPS support without delaying connection with
implementations that set Selected Registrar = 1 properly.
Generate a SHA1 hash -based UUID from the local MAC address if the UUID
was not configured. This makes it easier to prepare for WPS since there
is no need to generate an UUID.
This adds WPS support for both hostapd and wpa_supplicant. Both programs
can be configured to act as WPS Enrollee and Registrar. Both PBC and PIN
methods are supported.
Currently, hostapd has more complete configuration option for WPS
parameters and wpa_supplicant configuration style will likely change in
the future. External Registrars are not yet supported in hostapd or
wpa_supplicant. While wpa_supplicant has initial support for acting as
an Registrar to configure an AP, this is still using number of hardcoded
parameters which will need to be made configurable for proper operation.
Find attached the patch that creates a new driver: roboswitch. This
driver adds support for wired authentication with a Broadcom
RoboSwitch chipset. For example it is now possible to do wired
authentication with a Linksys WRT54G router running OpenWRT.
LIMITATIONS
- At the moment the driver does not support the BCM5365 series (though
adding it requires just some register tweaks).
- The driver is also limited to Linux (this is a far more technical
restriction).
- In order to compile against a 2.4 series you need to edit
include/linux/mii.h and change all references to "u16" in "__u16". I
have submitted a patch upstream that will fix this in a future version
of the 2.4 kernel. [These modifications (and more) are now included in
the kernel source and can be found in versions 2.4.37-rc2 and up.]
USAGE
- Usage is similar to the wired driver. Choose the interfacename of
the vlan that contains your desired authentication port on the router.
This name must be formatted as <interface>.<vlan>, which is the
default on all systems I know.
The scan path to initiate another scan if the initial association failed
was broken due to wpa_s->scan_req being zeroed earlier in
wpa_supplicant_scan(). This caused the second scan to bail out early
since it thought this was not a requested scan.
In situations where the driver does background scanning and sends a
steady stream of scan results, wpa_supplicant would continually
reschedule the scan. This resulted in specific SSID scans never
happening for a hidden AP, and the supplicant never connecting to the AP
because it never got found. Instead, if there's an already scheduled
scan, and a request comes in to reschedule it, and there are enabled
scan_ssid=1 network blocks, let the scan happen anyway so the hidden
SSID has a chance to be found.
