This is a (hopefully) temporary workaround to allow the same source code
tree to be used for building hostapd and wpa_supplicant without having
to manually force recompilation of some files. Currently, some of the
driver wrapper files need to be built separately for hostapd and
wpa_supplicant (#ifdef's in the files based on AP functionality).
This is somewhat racy as far as parallel make execution is concerned,
i.e., it may be necessary to run "make -j#" twice (plain "make" works
fine. Since this is supposed to be a temporary workaround, there is not
much point in trying to fix this with any more complex make processing.
Instead of having all driver stuff collected across wpa_supplicant
and hostapd, create a common snippet that they both include and
that handles the build configuration.
Instead of calling specific Probe Request handler functions, use a
generic mechanism that allows multiple callback functions to be
registered for getting notification on receive Probe Request frames.
The driver wrappers should not need to include wps_hostapd.h, so let's
make this easier by introducing a driver callback for reporting Probe
Request frames.
Previously, we would have allowed both the WPA and RSN EAPOL-Key
types to be used regardless of whether the association is using
WPA or RSN/WPA2. This shouldn't result in any significant problems
on the Authenticator side, but anyway, we should check the type and
ignore the EAPOL-Key frames that used unexpected type.
hostapd_cli wps_pin command can now have an optional timeout
parameter that sets the PIN lifetime in seconds. This can be used
to reduce the likelihood of someone else using the PIN should an
active PIN be left in the Registrar.
We could use auto-channel selection here eventually, but for now,
reject the configuration since it is not going to work correctly
(Beacon and Probe Response frames use incorrect value in DS Params).
Port the code from wpa_supplicant to re-use an existing ctrl_iface
socket file if the file does not seem to be in use. This allows
hostapd to recover from unclean shutdown of the control interface.
None of the driver wrappers user this. hostapd-controlled broadcast SSID
hiding can only be used with drivers that use hostapd for handling
Beacon and Probe Request/Response frames.
None of the driver wrappers use this. Only the drivers that use hostapd
for Beacon and Probe Request/Response handling can now use IEEE 802.11d
properly.
This was not really supported by any of the included driver wrappers. If
this functionality is desired in the future, this (or something similar)
can be added with the changes needed into a driver wrapper to use the
mechanism.
This simplifies driver wrapper operations and removes last direct
struct hostapd_data dereferences from driver_nl80211.c. In addition,
some of the TX callbacks are now fixed for secondary BSSes.
This fixes deauth/disassoc frames in secondary BSSes when using
multi-BSSID. In addition, it reduces need to dereference
struct hostapd_data inside driver wrappers.
Instead of adding a new driver_ops for fetching neighbor BSS data (that
nl80211 driver interface had to scan during initialization), share the
same scan operations that wpa_supplicant is using. This gets rid of
duplicated scan code in driver_nl80211.c (and better yet, removes large
part of old WEXT code).
hostapd interface initialization is now completed in a callback, if
needed, i.e., he_features channel/hw_mode selection can use as much time
as needed. This can also help with radar detection in the future.
Use a parameter structure to pass in information that can be more easily
extended in the future. Include some of the parameters that were
previously read directly from hapd->conf in order to reduce need for
including hostapd/config.h into driver wrappers.
This was not documented properly and was not really used nor would it be
suitable to be used in generic way as it was implemented. It is better
to just remove the parameter since there does not seem to be any
reasonable use for it.
This merges the driver wrapper implementations to use the same
implementation both for hostapd and wpa_supplicant operations to avoid
code duplication.
This commit merges the driver_ops structures and implementations from
hostapd/driver*.[ch] into src/drivers. This is only an initial step and
there is room for number of cleanups to share code between the hostapd
and wpa_supplicant parts of the wrappers to avoid unnecessary source
code duplication.
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.
