This commit merges the driver_ops structures and implementations from
hostapd/driver*.[ch] into src/drivers. This is only an initial step and
there is room for number of cleanups to share code between the hostapd
and wpa_supplicant parts of the wrappers to avoid unnecessary source
code duplication.
Need to set WEP keys before requesting authentication in order to get
Shared Key authentication working. Previously, the WEP keys were not set
at all when using SME in wpa_supplicant.
mac80211 does not use this type of Michael MIC event, so this is not
really used and proper Michael MIC failure processing will be added
using an nl80211 event once that gets added into wireless-testing.git.
It looks like both new nl80211 operations (scan and auth/assoc) end up
being added in Linux 2.6.30, so we do not need to maintain the backwards
compatibility code in wpa_supplicant.
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
This version is adding the configuration option (mode=2) for this and
driver capability reporting to figure out whether AP mode can be used.
However, this does not actually implement any real functionality yet.
Need to set drv->ifindex before calling set_mode(). In addition, set the
mode before setting the interface up to avoid having to set it down
again.
Add more useful error message on mode changes.
All these driver handlers can be implemented in associate() handler
which gets all the needed information in the parameters structure. The
old functions that provided only a single parameter will be removed
eventually to clean up the driver_ops structure, so driver wrappers
should start using the newer mechanism.
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.
This adds first part of FT resource request as part of Reassocition
Request frame (i.e., FT Protocol, not FT Resource Request Protocol).
wpa_supplicant can generate a test resource request when driver_test.c
is used with internal MLME code and hostapd can verify the FTIE MIC
properly with the included RIC Request.
The actual RIC Request IEs are not processed yet and hostapd does not
yet reply with RIC Response (nor would wpa_supplicant be able to
validate the FTIE MIC for a frame with RIC Response).
This is just there very first step on being able to do something with
wireless LAN on Vista. There is some example code for requesting a scan,
but it does not work in its current form. Anyway, this adds a wpa_printf
noting that Native 802.11 drivers are not yet supported.
This is done with wired interfaces to fix IEEE 802.1X authentication
when the authenticator uses the group address (which should be happening
with wired Ethernet authentication).
This allows wpa_supplicant to complete wired authentication successfully
on Vista with a NDIS 6 driver, but the change is likely needed for
Windows XP, too.
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.
These flags are used to mark which values (level, noise, qual) are
invalid (not available from the driver) and whether level is using dBm.
D-Bus interface will now only report the values that were available.
This does not actually send out separate scan requests for each SSID,
but the debug output can be used to test scan2() functionality with
multiple SSIDs.
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).
For example, -Dnl80211,wext could be used to automatically select
between nl80211 and wext. The first driver wrapper that is able to
initialize the interface will be used.
This workaround was needed with some drivers that used WEXT, but there
is no known nl80211-enabled driver that would need this, so lets get rid
of the extra delay.
The driver wrappers can now inform wpa_supplicant how many SSIDs can
be used in a single scan request (i.e., send multiple Probe Requests
per channel). This value is not yet used, but it can eventually be used
to allow a new scan command to specify multiple SSIDs to speed up
scan_ssid=1 operations. In addition, a warning could be printed if
scan_ssid=1 is used with a driver that does not support it
(max_scan_ssids=0).
Some drivers (for example ipw2100) do not report signal level but only
signal quality. wpa_supplicant already uses the signal quality if no
level is reported and all other comparision parameters are equal to sort
the scan results. However, if two APs have different max rates and the
signal level does not differ much wpa_supplicant chooses the AP with the
higher max rate.
In case of ipw2100 no signal level is reported and thus wpa_supplicant
always takes the AP with higher max rate even if its signal quality is
really low. For example if AP1 (max rate 11Mb/s, 80% signal quality) and
AP2 (max rate 54 Mb/s, 20% signal quality) are found by a scan
wpa_supplicant would choose AP2.
Hence, if no signal level is reported depend on the signal quality if
max rate should be compared. A quality difference of 10% is considered
acceptable in favor of the higher max rate.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Really disassociate when tearing stuff down; drivers may sometimes
(legally) keep trying to reassociate unless the BSSID is unlocked. If
the SSID is unlocked too, under WEXT drivers are able to pick an SSID to
associate, so kill that behavior by setting a bogus SSID. Unfortunately
WEXT doesn't provide an easy method to say "stop whatever doing and just
idle".
Signed-off-by: Dan Williams <dcbw@redhat.com>