(jm: This is based on the Android change that used driver_cmd. The same
implementation is used for the actual driver interface, but the commands
are now accessed through sched_scan/stop_sched_scan driver_ops instead
of driver_cmd)
WEXT is not really changing anymore and more or less all Linux
distros come with linux/wireless.h that is recent enough to
allow the driver wrappers to be build.
Signed-hostap: Jouni Malinen <j@w1.fi>
Some dualband cards can use more than five seconds to run through
a full scan, so increase the timeout to avoid hitting the missing
scan completed event workaround.
Previously, both NULL and ff:ff:ff:ff:ff:ff addr were used in various
places to indicate default/broadcast keys. Make this more consistent
and useful by defining NULL to mean default key (i.e., used both for
unicast and broadcast) and ff:ff:ff:ff:ff:ff to indicate broadcast
key (i.e., used only with broadcast).
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>
wpa_supplicant showed signal levels incorrectly with some drivers:
Jun 6 16:29:36 rupert wpa_supplicant[18945]: Current BSS: 00:0d:97:11:40:d6
level=190
Jun 6 16:29:36 rupert wpa_supplicant[18945]: Selected BSS: 00:0d:97:11:50:09
level=192
Judging from output from other tools (iwlist) and the min_diff block
at the end of wpa_supplicant_need_to_roam, it seems these values
should actually be negative. Specifically, if one treats that number
as a signed char instead of unsigned, everything matches up.
To be honest, I've little to no understanding of wireless, but looking
at the source code for wireless-tools (iw_print_stats in iwlib.c), it
seems that the fields of the iw_quality struct need to be decoded
differently depending on various flags. I guess
src/drivers/driver_wext.c should have similar logic in
wext_get_scan_qual.
I wrote a patch that attempts to replicate some of that logic,
although it may be more complicated than is necessary; I think some of
the complexity is for backwards-compatibility, which might not be
necessary depending on wpa_supplicant's dependencies? In any case, it
is attached. Again, I don't know how any of this works, so it's likely
the patch is a bit off. But I think at least the logic to determine
min_diff in wpa_supplicant_need_to_roam would be more accurate if
level were determined correctly.
Replace use of rfkill block event with rtnetlink ifdown. This makes
the design more robust since the rfkill event could have been for
another interface while the rtnetlink events are already filtered
based of ifindex. In addition, the new design handles other than
rfkill-triggered ifdown/ifup events, too. rfkill unblocked event
is still needed to try to set the interface back up. If the unblock
was for another interface, ifup will fail and the driver state is
not changed.
Add a new wpa_supplicant state: interface disabled. This can be used
to allow wpa_supplicant to be running with the network interface even
when the driver does not actually allow any radio operations (e.g.,
due to rfkill).
Allow driver_nl80211.c and driver_wext.c to start while rfkill is in
blocked state (i.e., when ifconfig up fails) and process rfkill
events to block/unblock WLAN.
If the driver is detected to use cfg80211, we can rely on it being able
to disconnect with SIOCSIWMLME commands and to use empty SSID as a way
to stop it from associating when we are in progress of configuring the
driver for association. Consequently, we can remove the hack that uses
random 32-octet SSID to force disconnection and re-order association
commands to match the expectations that cfg80211 has for WEXT ioctls.
This gets rid of extra scan rounds and attempts to associate with the
silly 32-octet SSID.
Number of Linux driver wrappers included this more or less identical
function, so lets add a new helper file to be able to share some more
code between the driver wrappers.
There does not seem to be a driver interface for fetching auth_algs
capability, but this may be used by some external application, so
hardcode all auth_algs as supported for now.
As an initial step in sharing netlink helper functions among driver
wrappers, create a new file for netlink code and move operstate send
function there.
This makes it clearer which files are including header from src/common.
Some of these cases should probably be cleaned up in the future not to
do that.
In addition, src/common/nl80211_copy.h and wireless_copy.h were moved
into src/drivers since they are only used by driver wrappers and do not
need to live in src/common.
This gets rid of previously deprecated driver_ops handlers set_wpa,
set_drop_unencrypted, set_auth_alg, set_mode. The same functionality
can be achieved by using the init/deinit/associate handlers.
gcc 4.4 ends up generating strict-aliasing warnings about some very common
networking socket uses that do not really result in a real problem and
cannot be easily avoided with union-based type-punning due to struct
definitions including another struct in system header files. To avoid having
to fully disable strict-aliasing warnings, provide a mechanism to hide the
typecast from aliasing for now. A cleaner solution will hopefully be found
in the future to handle these cases.
To ensure the supplicant starts and ends with a clean slate (keys are
already cleaned up at init and deinit time), force a null BSSID and
bogus SSID to ensure the driver isn't connected to anything.
Signed-off-by: Dan Williams <dcbw@redhat.com>
4853d5ac84 had a small bug in the order
of these function calls in _wext_deauthenticate() (_disassociate()
did have the correct order). The deauthentication frame is supposed
to go out (if driver supports that) before we disconnect more
forcefully.
Otherwise the driver might interpret the request as a request to
create/join a new adhoc network with the bogus SSID.
Signed-off-by: Dan Williams <dcbw@redhat.com>
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.
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.
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).
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>
We can now handle up to 65535 byte result buffer which is the maximum
due to WEXT using 16-bit length field. Previously, this was limited to
32768 bytes in practice even through we tried with 65536 and 131072
buffers which we just truncated into 0 in the 16-bit variable.
This more or less doubles the number of BSSes we can received from scan
results.
This is needed for airo driver to work correctly and no other driver
seems to care, so the change is safe to make. This has been in number of
distro releases for a long time and no issues have been reported.
Remove the old code from driver_wext.c since the private ioctl interface is
never going to be used with mac80211. driver_nl80211.c has an
implementation than can be used with mac80211 (with two external patches to
enable userspace MLME configuration are still required, though).
A bug just got reported as a result of this for mac80211 drivers.
https://bugzilla.redhat.com/show_bug.cgi?id=459399
The basic problem is that since taking the device down clears the keys
from the driver on many mac80211-based cards, and since the mode gets
set _after_ the keys have been set in the driver, the keys get cleared
on a mode switch and the resulting association is wrong. The report is
about ad-hoc mode specifically, but this could happen when switching
from adhoc back to managed mode.
If IWEVGENIE or custom event wpa_ie/rsn_ie is received in scan with empty
buffer, the previous version ended up calling realloc(NULL, 0) which seems
to return a non-NULL value in some cases. When this return value is passed
again into realloc with realloc(ptr, 0), the returned value could be NULL.
If the ptr is then freed (os_free(data.ie) in SIOCGIWAP handling), glibc
may crash due to invalid pointer being freed (or double-freed?). The
non-NULL realloc(NULL, 0) return value from glibc looks a bit odd behavior,
but anyway, better avoid this case completely and just skip the IE events
that have an empty buffer.
This issue should not show up with drivers that produce proper scan results
since the IEs will always include the two-octet header. However, it seems
to be possible to see this when using 64-bit kernel and 32-bit userspace
with incorrect compat-ioctl processing.
Network device ifindex will change when the interface is re-inserted.
driver_wext.c will need to accept netlink events from "unknown" (based on
ifindex) interfaces when a previously used card was removed earlier. If the
previously removed interface is added back, the driver_wext data need to be
updated to match with the new ifindex value. In addition, the initial setup
tasks for the card (set interface up, update ifindex, set mode, etc.) from
wpa_driver_wext_init() need to be run again.
When scan results got moved from wpa_scan_result -> wpa_scan_res, the
'maxrate' member was dropped from wpa_scan_res. The D-Bus interface
used 'maxrate', which was replaced with wpa_scan_get_max_rate().
Unfortunately, wpa_scan_get_max_rate() returns 802.11 rate values
directly from the IE, where 'maxrate' was the rate in bits/second. The
supplicant internally fakes an IE for wpa_scan_res from the value of
wpa_scan_result->maxrate, but interprets ->maxrate as an 802.11 rate
index.
As a side-effect, this fixes a soft-break of the D-Bus control API since
the wpa_scan_res change was introduced.
