This fixes multi-BSS configuration with driver_nl80211.c to mark STAs
that use secondary BSSes with open/static WEP without having to make
driver_nl80211.c track 802.1X configuration for each BSS.
Static WEP keys were configured only for the first BSS. In addition,
STAs were flushed only for the first BSS. These operations should be in
hostapd_setup_bss(), not setup_interface().
Remove extra call to ieee802_11_set_beacon() for the first BSS. This
should only be done from hostapd_setup_bss(), i.e., once for each BSS.
No need for a separate driver_ops handler for setting DTIM period since
this is always set at the same time with the Beacon data. Beacon
interval is still set separately since it is consider per-radio
parameter (Beacon data and DTIM period are per-BSS parameters).
IEEE 802.11r KDF uses key length in the derivation and as such, the PTK
length must be specified correctly. The previous version was deriving
using 512-bit PTK regardless of the negotiated cipher suite; this works
for TKIP, but not for CCMP. Update the code to use proper PTK length
based on the pairwise cipher.
This fixed PTK derivation for both IEEE 802.11r and IEEE 802.11w (when
using AKMP that specifies SHA-256-based key derivation). The fixed
version does not interoperate with the previous versions. [Bug 307]
Move the shared IEEE 802.11w enum definition into src/common/defs.h to
avoid redefinition when both configuration structures are included into
the same file.
The actual pointer to struct sta_info was not really used and it is
enough to use a single bit to indicate whether an AID is allocated. This
makes the BSS data take less memory while making the allocation routine
faster and removing the arbitrary MAX_AID_TABLE_SIZE limit of 128 STAs.
Remove all fields before sun_path before printing or comparing sun_path
contents. Using offsetof should be portable. In addition, set sun_len
for FreeBSD.
This was broken by 510c02d4a3 which added
validation of eap_ttls_phase2_eap_init() return value. The main problem
in the code trying to initialize a new phase 2 EAP method
unconditionally; this should only happen if there is a new method in the
inner method sequence.
If every secondary BSS is configured with a pre-set BSSID, hostapd does
not enforce the BSSID mask requirements anymore, i.e., they are used
only if hostapd is responsible for generating MAC addresses for virtual
interfaces.
This is needed to make mac80211 work with multi-BSS configuration. The
previous design ended up setting DTIM period for secondary BSSes before
setting the Beacon and driver_nl80211.c was not really prepared for
that. Eventually, the Beacon configuration routines should be combined
into a single driver operation, but for now, just moving this call is
the simplest workaround.
hostapd will now go through the RIC Request and process each RDIE. Only
WMM TSPEC requests are currently supported; all other request
descriptors will be declined.
RIC Response is written by hostapd and verified by wpa_supplicant (MIC
validation). wpa_supplicant does not yet have code to notify the driver
about the resource request results.
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).
Windows XP and Vista clients can get confused about EAP-Identity/Request
when they probe the network with EAPOL-Start. In such a case, they may
assume the network is using IEEE 802.1X and prompt user for a
certificate while the correct (non-WPS) behavior would be to ask for the
static WEP key. As a workaround, use Microsoft Provisioning IE to
advertise that legacy 802.1X is not supported.
This seems to make Windows ask for a static WEP key when adding a new
network, but at least Windows XP SP3 was still marking IEEE 802.1X
enabled for the network. Anyway, this is better than just leaving the
network configured with IEEE 802.1X and automatic WEP key distribution.
