This allows the accept_mac_file to be used as an alternative for RADIUS
server-based configuration. This is mainly to ease VLAN testing (i.e., no
need to set up RADIUS server for this anymore).
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.
sssleay.num had changed (new function allocated) and server code was
modified to call ssl3_digest_cached_records() in the start of abbreviated
handshake to avoid possible segmentation faults later in some cases when
reverting to full handshake. In addition, there is some whitespace cleanup
and added comment explaining TLS ticket processing.
When the TLS handshake had been completed earlier by the server in case of
abbreviated handshake, the output buffer length was left uninitialized. It
must be initialized to zero in this case. This code is used by EAP-FAST
server and the uninitialized length could have caused it to try to send a
very large frame (though, this would be terminated by the 50 roundtrip EAP
limit). This broke EAP-FAST server code in some cases when PAC was used to
establish the tunnel.
The configuration data should only store the static configuration data and
not dynamic data. In addition, storing HT configuration and state in IEs is
not the easiest way of doing this, so use more convenient data types for
storing configuration and dynamic state. The HT IEs are then generated
based on the static configuration and dynamic state whenever needed.
This commit brings in cleaned up version of IEEE 802.11n implementation
from Intel (1). The Intel tarball includes number of other changes, too,
and only the changes specific to IEEE 802.11n are brought in here. In
addition, this does not include all the changes (e.g., some of the
configuration parameters are still missing and driver wrapper changes for
mac80211 were not included).
(1)
http://www.kernel.org/pub/linux/kernel/people/chuyee/wireless/iwl4965_ap/hostap_0_6_0_intel_0.0.13.1.tgz
These functions are based on the hostapd implementation and complete
the userspace MLME code in wpa_supplicant (though, mac80211 will still need
couple of pending patches to be integrated in order to get userspace client
MLME working again).
This adds some parts needed to use usermode MLME with the current mac80211
(plus a patch to add a new cfg80211 command; not yet submitted to
wireless-testing). This version creates a monitor interface for management
frames and is able to send Probe Request frames during scan. However, it
looks like management frame reception is not yet working properly. In
addition, mlme_{add,remove}_sta() handlers are still missing.
Network device ifindex will change when the interface is re-inserted.
driver_nl80211.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_nl80211_init() need to be run again.
This is the changes from commit 3fbda8f943
(driver_wext.c) ported for driver_nl80211.c.
This new cfg80211 command is used for setting CTS protect, short preamble,
and short slot time parameters for the BSS. The matching kernel change has
been submitted, but is not yet included in wireless-testing. The code here
used #ifdef to avoid compilation failures before the new command is
available.
wpa_sm_set_config() can be called even if the network block does not
change. However, the previous version ended up calling
pmksa_cache_notify_reconfig() every time and this cleared the network
context from PMKSA cache entries. This prevented OKC from ever being used.
Do not call pmksa_cache_notify_reconfig() if the network context remains
unchanged to allow OKC to be used.
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.
The change to support fragmentation added extra function to generate the
EAP header, but forgot to remove the original code and ended up getting two
EAP headers and TNC flags field in the generated message. These header
fields need to be added only in the function that builds the final message
(and if necessary, fragments the data).
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.
Function 'wpa_sm_set_config' used the argument 'config' as the network
context which is a pointer to a local variable of the function
'wpa_supplicant_rsn_supp_set_config'.
This is one reason why no proactive key was generated. This network
context never matched with the network context saved in the pmksa cache
entries.
The structure 'rsn_supp_config' has already a member 'network_ctx' which
is now filled in by this patch with 'ssid'.
Signed-off-by: Michael Bernhard <michael.bernhard@bfh.ch>
Documentation appeared a little vague about which options are global and
which are tied to a particular interface. This leads to confusion when
using certain combinations of options, e.g. the command "wpa_supplicant
-c /etc/wpa_supplican.conf -u" will not do what is intuitively expected
from it - it will not read the config file given with -c option because
no -i option was given. This command is still valid because -u option is
used. The wpa_supplicant running like this will also not listen on any
control socket, because the socket file name is usually given in the
config file. This command line also happens to be the default in Fedora 9.
This patch does not try to change any behaviour, but rather document
these nuances clearly.
Added code to use suggested nl80211/cfg80211 API for setting MFP related
parameters. This is disabled by default since the API changes has not yet
been approved. The new commands can be enabled by defining
NL80211_MFP_PENDING (this will be removed once the API changes is
approved).
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>
Add the new flags which are supposed to be included in Linux 2.6.27
for the drivers which want to do 4-way handshake and to know PMK.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
This new netdev is created by hwsim, not mac80211, and as such, it is
available all the time (i.e., can be UP before starting mac80211 netdevs)
and it will receive all frames regardless of the channel etc.
