While this is not strictly speaking required based on dynamic
configuration (i.e., dot11ShortPreambleOptionImplemented is static
value based on implementation, not runtime configuration), it is better
to follow local configuration parameter for short preamble in addition
to the associated station capabilities.
This function is not really needed in case of drivers that build the
HT IEs internally. However, since this can get called if ieee80211n=1
is set in hostapd.conf, we better not segfault even if the driver
does not provide hw info (hapd->iface->current_mode == NULL).
Commit 5a1cc30f1a added code that was
assuming CONFIG_WPS_UPNP is enabled whenever CONFIG_WPS is. Fix this
by making the UPnP calls conditional on CONFIG_WPS_UPNP define.
hostapd simply used its own STBC configuration in the STA's HT caps. This
resulted in TX STBC being used for STAs not supporting RX STBC, which in
turn resulted in the STA not receiving anything.
Fix this by handling the STBC flags in the same way mac80211 does. Mask
out RX STBC if we don't support TX STBC and vice versa.
Tested only with the nl80211 driver and a STBC incapable STA.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
A new hostapd_cli command, wps_ap_pin, can now be used to manage
AP PIN at runtime. This can be used to generate a random AP PIN and
to only enable the AP PIN for short period (e.g., based on user
action on the AP device). Use of random AP PIN that is only enabled
for short duration is highly recommended to avoid security issues
with a static AP PIN.
As a compromise between usability and security, do not disable
AP PIN permanently based on failed PIN validations. Instead, go to
AP Setup Locked state for increasing amount of time between each
failure to slow down brute force attacks against the AP PIN.
This avoids problems with some external Registrars that may try
to use the same PIN multiple times without user input. Now, the
user will still be able to fix the PIN and try again later while
a real attack is delayed enough to make it impractical.
In theory, this should not really be needed, but Windows 7 uses
Registrar mode to probe AP's WPS capabilities before trying to use
Enrollee and fails if the AP does not allow that probing to happen.
This allows the AP to start as an Enrollee and send M1, but refuse
to continue beyond that (M3 will not be sent if AP PIN is not known).
This makes it easier (and a bit faster) to handle multiple local
radios with FT. There is no need to depend on l2_packet in that
case since the frame can be delivered as a direct function call.
If the station does not include WSC IE in Association Request, it
is marked with WLAN_STA_MAYBE_WPS flag. We can update that to
WLAN_STA_WPS if the station uses either of the WPS identity strings.
This enables some workarounds for WPS stations.
The pairwise cipher field is supposed to be little endian, but the
message building functions did not swap the bytes on big endian
hosts while the message processing functions did. Fix this by using
little endian byte order in both places.
Some frequent debug prints are of limited use and make debug output
difficult to read. Make them use a new debug level so that -dd
provides more readable output (-ddd can now be used to enable
the excessive debug prints).
Some of the driver wrappers need to get set_ieee8021x() call before
they can configure keys. Reorder the operations in the reloading
of configuration case to match with that expectation.
If the associating station indicates that it is intents to use WPS
by including WPS IE in (Re)Association Request frame, include WPS IE
in (Re)Association Response frame.
Vendor-specific IEs are supposed to be in the end of the frame, so move
WMM into the end of Beacon, Probe Response, and (Re)Association Response
frames. In addition, move HT IEs to be later in (Re)Association
Response to match the correct order.
hostapd_eid_wpa() adds multiple IEs and the end result may not always be
correct. If WPA is enabled, WPA IE (vendor-specific) gets added in the
middle of the frame and not in the end. This would require a larger
change to spliut the IEs from WPA module into separate locations when
constructing Beacon and Probe Response frames. This is not yet addressed.
Commit c02d52b405 removed direct calls
to the WPA authenticator, but the change here was incorrect.
EAPOL_SM_USES_WPA was supposed to be set based on sta->wpa_sm being
set, i.e., no need to check for PMKSA entries for that.
While this could potentially change EAPOL Key TX state machine behavior,
no clear problems have been identified so far. Anyway, better fix this
to get the correct flags set for EAPOL authenticator state machine.
When using WPS, we may end up here if the STA manages to re-associate
without the previous STA entry getting removed. Consequently, we need to
make sure that the WPA state machines gets initialized properly at this
point.
There are no subdirectories in any of these directories or plans
for adding ones. As such, there is no point in running the loop
that does not do anything and can cause problems with some shells.
Both the wildcard VLAN entry and the statically configured VLAN
interfaces should behave in the same way. Initializing the
full dynamic VLAN code before adding the statically configured VLAN
interfaces allows the same processing to be applied to both statically
and dynamically added VLAN interface (i.e., also the statically
configured ones will be added to a bridge).
The WPS IE was overriding the WPA/RSN IE in driver based MLME case
(hostapd_notif_assoc), but the MLME code here was not using WPS IE
correctly, i.e., it allowed the WPA/RSN IE override the operation.
There is no absolute requirement for separating address allocation
into separate functions, so simplify the driver wrapper interface
to use just if_add and if_remove instead of adding the new
alloc_interface_addr() and release_interface_addr() functions.
if_add() can now indicate if the driver forced a different interface
name or address on the virtual interface.
hostapd does not implement UAPSD functionality. However, if U-APSD
functionality is implemented outside hostapd, add support to advertise
the functionality in beacon.
Signed-off-by: yogeshp@marvell.com
ANonce, SNonce, R0KH-ID, and R1KH-ID must match with the values
used in the previous FT authentication sequence message per
IEEE Std 802.11r-2008, 11A.8.4.
We do not have any keys set at this point so there is no point in
adding the MIC. In addition, IEEE Std 802.11r-2008, 11A.4.2
describes this frame to have MIC IE count of 0 and MIC of 0.
IEEE Std 802.11r-2008, 11A.4.2 describes FT initial mobility domain
association in an RSN to include PMKR1Name in the PMKID-List field
in RSN IE in messages 2/4 and 3/4. This makes the RSN IE not be
bitwise identical with the values used in Beacon, Probe Response,
(Re)association Request frames.
The previous versions of wpa_supplicant and hostapd did not add the
PMKR1Name value in EAPOL-Key frame and did not accept it if added
(due to bitwise comparison of RSN IEs). This commit fixes the
implementation to be compliant with the standard by adding the
PMKR1Name value into EAPOL-Key messages during FT 4-Way Handshake and
by verifying that the received value matches with the value derived
locally.
This breaks interoperability with previous wpa_supplicant/hostapd
versions.
Running hostapd and wpa_supplicant on the same interface at the same
time is not expected to work, but it should not cause hostapd to crash.
Ignore station mode association events (no addr field) to avoid this.
IF WPA/RSN parameters were changed or WPA/RSN was disabled, the
WPA/RSN IE in Beacon/Probe Response frames was only update with
set_beacon(). We need to do this with set_generic_elem(), too, to
work with all driver wrappers.
Call ieee802_11_set_beacon() in addition to set_ap_wps_ie() when
processing WPS IE updates. This is needed with drivers that use
set_beacon() instead of set_ap_wps_ie() (i.e., nl80211).
It turns out that this is needed for both FT-over-DS and FT-over-air
when using mac80211, so it looks easiest to just unconditionally
re-configure the keys after reassociation when FT is used.
This is needed to allow reassociation processing to skip 4-way handshake
when FT-over-DS is used with an AP that has a previous association state
with the STA.
This seems to be needed at least with mac80211 when a STA is using
FT-over-DS to reassociate back to the AP when the AP still has the
previous association state.
This makes the call simpler for driver wrappers since there is no need
to parse the IEs anymore before indicating association. In addition,
this allows association processing to be extended to use other IEs
in the future.
IGTK get_seqnum needs to be skipped in the same way as GTK one when
rekeying group keys. Previously, the old PN value (the one from the
previous key) was indicated and that resulted in MMIE replay detection
at the station.
Must update sm->pairwise when fetching PMK-R1 SA.
Add a workaround for drivers that cannot set keys before association
(e.g., cfg80211/mac80211): retry PTK configuration after association.
This is needed to fix PTK derivation to use correct length. Previously,
64-octet PTK may have been derived if the authenticator did not already
have a STA entry. Now, the correct pairwise cipher suite is learned when
then PMK-R1 SA is received.
With this patch, a client gets kicked out of the last BSS it was
attached to, when it is associating to a different one.
While mac80211 does allow a station to be present on multiple bss
interfaces, this does seem to cause problems both for the stack
and for hostapd.
This patch allows the nl80211 driver to create its own per-bss context
and pass it to the drv_priv pointer of the hostapd bss state.
With this and the following patch, stations can associate to and switch
between multiple BSS interfaces of a single wiphy.
This obsoletes a few instances of passing ifname to a callback, those
can be removed in a separate patch.
It might also be useful to move more fields from the driver data to the
per-bss data structure in the future.
This patch moves the authentication server setup before
IEEE 802.1X initialization. It's because 802.1X already
needs to have a valid SSL context.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
wpa_sm_step() could theoretically free the statemachine, but it does
not do it in this particular case. Anyway, the code can be cleaned to
verify whether the state machine data is still available after the
wpa_sm_step() call.
wmm_ac_??_cw{min,max} parameters are in log form
When the wme_ac_??_cw{min,max} parameters aren't specified in
hostapd.conf, hostapd uses an incorrect set of default values, as the
defaults are in 2^x-1 form instead of in log form. This patch changes
them over to the expected log form.
The three existing enums were already depending on using the same
values in couple of places and it is just simpler to standardize on
one of these to avoid need for mapping between different enums for
the exact same thing.
Most of this file was already moved into wpa_supplicant/scan.c and
we can remove the file completely by having couple of small helper
functions copied to the remaining users outside core wpa_supplicant
code.
This allows the driver interface to be deinitialized before
struct hostapd_data instance gets freed. This needs to be done so
that the driver wrapper does not maintain a context pointer to
freed memory.
Doxygen and some build tools may get a bit confused about same file
name being used in different directories. Clean this up a bit by
renaming some of the duplicated file names in src/ap.
This code can be shared by both hostapd and wpa_supplicant and this
is an initial step in getting the generic code moved to be under the
src directories. Couple of generic files still remain under the
hostapd directory due to direct dependencies to files there. Once the
dependencies have been removed, they will also be moved to the src/ap
directory to allow wpa_supplicant to be built without requiring anything
from the hostapd directory.
