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.
Just in case, do not use the not-yet-approved WEXT changes even if someone
where to build wpa_supplicant with IEEE 802.11w support unless this new
macro has been defined explicitly.
Added configuration of MFP related parameters with WEXT. The changes to
linux/wireless.h have not yet been applied to the Linux kernel tree, so the
code using them is still open to changes and is ifdef'ed out if
CONFIG_IEEE80211W is not set.
Add the support for the Linux wireless drivers which want to do
4-way handshake and need to know the PSK before the handshake.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Since mac80211 requires that the device be !IFF_UP to change the mode
(and I think the old prism54 fullmac driver does too), do that. This
shouldn't harm fullmac devices since they can handle mode switches on
the fly and usually don't care about up/down that much.
mac80211 sends _both_ channel and frequency in it's scan results, with
frequency first and channel second (it's since been fixed to send
channel first and frequency second to work around this issue). This
results in wpa_supplicant getting the right value when the frequency
comes, but overwriting the value with '0' when the channel comes because
wpa_supplicant can't handle 5GHz channel numbers. So if a valid
previous SIOCGIWFREQ event came in, don't try to overwrite it.
This adds support for PS3 wireless to wpa_supplicant.
Although PS3 wireless driver is designed to conform the WEXT standard
as much as possible, unfortunately the wext driver wrapper of
wpa_supplicant can not support PS3 wireless fully because:
- PS3 wireless driver uses private WEXT ioctls for accepting PSK of
WPA-Personal from the userland.
WEXT does not specify the way to do it.
- The association and 4-way handshake are done by PS3 virtual
wireless device. The guest OSes can not interfere it.
- No EAPOL frames are allowed to go outside of the
hypervisor/firmware nor come from. They are eaten by the firmware.
Thus I needed to make a new driver wrapper for PS3 wireless.
This patch can be applied against the latest 0.6.x tree.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
These are expected in most cases and there is no need to confuse users
with the messages in stderr (perror was used here). These are now only
shown in debug output and EOPNOTSUPP errors are silently ignored.
