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.
