The nl80211 driver can report low ACK condition (in fact it reports
complete loss right now only). Use that, along with a config option, to
disconnect stations when the data connection is not working properly,
e.g., due to the STA having went outside the range of the AP. This is
disabled by default and can be enabled with disassoc_low_ack=1 in
hostapd or wpa_supplicant configuration file.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The frame needs to be sent from an individual (non-group) address,
so drop invalid frames before sending Deauth/Disassoc frames to
not associated STAs.
Getting rid of these inline functions seems to reduce the code size
quite a bit, so convert the most commonly used hostapd driver ops to
function calls.
This is not needed anymore and just makes things more difficult
to understand, so move the remaining function pointers to direct
function calls and get rid of the struct hostapd_driver_ops.
send_eapol, set_key, read_sta_data, sta_clear_stats,
set_radius_acl_auth, set_radius_acl_expire, and set_beacon
to use inline functions instead of extra abstraction.
Commit bf65bc638f started the path to
add this new abstraction for driver operations in AP mode to allow
wpa_supplicant to control AP mode operations. At that point, the
extra abstraction was needed, but it is not needed anymore since
hostapd and wpa_supplicant share the same struct wpa_driver_ops.
Start removing the unneeded abstraction by converting
send_mgmt_frame() to an inline function, hostapd_drv_send_mlme().
This is similar to the design that is used in wpa_supplicant and
that was used in hostapd in the past (hostapd_send_mgmt_frame()
inline function).
On Linux, verify that the kernel entropy pool is capable of providing
strong random data before allowing WPA/WPA2 connection to be
established. If 20 bytes of data cannot be read from /dev/random,
force first two 4-way handshakes to fail while collecting entropy
into the internal pool in hostapd. After that, give up on /dev/random
and allow the AP to function based on the combination of /dev/urandom
and whatever data has been collected into the internal entropy pool.
wlan0: RADIUS No authentication server configured
MEMLEAK[0x999feb8]: len 1040
WPA_TRACE: memleak - START
[3]: ./hostapd(radius_msg_new+0x33) [0x8074f43]
radius_msg_new() ../src/radius/radius.c:117
[4]: ./hostapd() [0x806095e]
ieee802_1x_encapsulate_radius() ../src/ap/ieee802_1x.c:439
ieee802_1x_aaa_send() ../src/ap/ieee802_1x.c:1496
For example, this error occured when I used WPS hostapd without
"eap_server=1" definition in configuration file.
By default, make hostapd and wpa_supplicant maintain an internal
entropy pool that is fed with following information:
hostapd:
- Probe Request frames (timing, RSSI)
- Association events (timing)
- SNonce from Supplicants
wpa_supplicant:
- Scan results (timing, signal/noise)
- Association events (timing)
The internal pool is used to augment the random numbers generated
with the OS mechanism (os_get_random()). While the internal
implementation is not expected to be very strong due to limited
amount of generic (non-platform specific) information to feed the
pool, this may strengthen key derivation on some devices that are
not configured to provide strong random numbers through
os_get_random() (e.g., /dev/urandom on Linux/BSD).
This new mechanism is not supposed to replace proper OS provided
random number generation mechanism. The OS mechanism needs to be
initialized properly (e.g., hw random number generator,
maintaining entropy pool over reboots, etc.) for any of the
security assumptions to hold.
If the os_get_random() is known to provide strong ramdom data (e.g., on
Linux/BSD, the board in question is known to have reliable source of
random data from /dev/urandom), the internal hostapd random pool can be
disabled. This will save some in binary size and CPU use. However, this
should only be considered for builds that are known to be used on
devices that meet the requirements described above. The internal pool
is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
This adds more time for the system entropy pool to be filled before
requesting random data for generating the WPA/WPA2 encryption keys.
This can be helpful especially on embedded devices that do not have
hardware random number generator and may lack good sources of
randomness especially early in the bootup sequence when hostapd is
likely to be started.
GMK and Key Counter are still initialized once in the beginning to
match the RSN Authenticator state machine behavior and to make sure
that the driver does not transmit broadcast frames unencrypted.
However, both GMK (and GTK derived from it) and Key Counter will be
re-initialized when the first station connects and is about to
enter 4-way handshake.
The example GMK-to-GTK derivation described in the IEEE 802.11 standard
is marked informative and there is no protocol reason for following it
since this derivation is done only on the AP/Authenticator and does not
need to match with the Supplicant. Mix in more data into the derivation
process to get more separation from GMK.
There is no point in maintaining two almost identical versions
of this parser. Move WPA IE parser into wpa_common.c similarly
to what was already the case with RSN IE parse.
WPS external Registrars can get confused about multiple UPnP
instances (one per radio) on a dual-concurrent APs. Simplify the
design by sharing a single UPnP state machine for all wireless
interfaces controlled by hostapd. This matches with the previous
changes that made a single command enable WPS functionality on
all interfaces.
This is relatively minimal change to address the sharing of the
state among multiple struct hostapd_data instances. More cleanup
can be done separately to remove unnecessary copies of information.
Commit c3fc47ea8e fixed EAP passthrough
server to allow Logoff/Re-authentication to be used. However, it
broke EAP standalone server while doing that. Fix this by reverting
the earlier fix and by clearing the EAP Identity information in the
EAP server code whenever an EAPOL-Start or EAPOL-Logoff packet is
received.
These are not used by any driver wrapper, i.e., only the four
data queues (BK, BE, VI, VO) are configurable. Better remove these
so that there is no confusion about being able to configure
something additional.
This is needed to avoid problems with other applications setting and
leaving the interface to IF_OPER_DORMANT state. In AP mode, the interface
is ready immediately after the keys are set, so we better make sure the
DORMANT state does not prevent normal operations after that.
Some driver wrappers may end up indicating a disassociation or
deauthentication event without the address of the station, e.g.,
based on a previous non-AP mode event. Avoid crashing hostapd
by verifying that the require address parameter is available in
the event before processing it.
This test command is supposed to change the WPS version number in all
places immediately, so make sure that the IEs used in management
frames get updated immediately.
The P2P group component is now tracking of associated stations
in the group and the Group Limit bit in the Group Capabilities
is updated based on whether there is room for new clients in
the group.
The AP operation with wpa_supplicant requires an additional callback
to get the needed event information from hostapd side so that
wpa_msg() can be called for wpa_s->parent if needed.
When a single hostapd process is controlling multiple interfaces,
apply the received or auto-generated configuration changes to all
interfaces that have enabled WPS.
When the same hostapd process is controlling multiple interfaces,
apply WPS commands (push button, add PIN, change AP PIN) to all
interfaces that are configured to use WPS.
Commit 3379a3a795 added a direct
iface->for_each_interface use without verification whether the
function is available. This works with hostapd, but not
wpa_supplicant (which crashes on segfault).
The previous implementation ended up incorrectly assuming that all
40 MHz use cases have secondary channel above the primary one. Fix this
by properly masking the secondary channel offset field and checking its
value.
This is needed to update the pointers maintained within WPS code
to use the new configuration data instead of maintaining pointers
to the old configuration which will be freed. This fixes strings in
UPnP discovery after reconfig (they used to be random freed memory..).
This seems to be the easiest way of making sure the Config Methods
value is compliant with the WSC 2.0 specification without having
to modify the configuration file. However, this will only add the
virtual flag, so the configuration files should really be updated
to specify values that match the AP design.
WPS 2.0 mandates the AP to include WPS IE in (Re)Association Response
if the matching (Re)Association Request included WPS IE. Provide the
needed WPS IE information to the driver_ops API for drivers that
process association frames internally.
Note: This modifies the driver_ops API by adding a new argument to
set_ap_wps_ie().
The Beacon frame must include UUID-E and RF Bands attributes when
in active PBC mode to allow stations to figure out that two BSSes in
PBC mode is not a PBC session overlap.
When generating the UUID based on MAC address, share the same UUID
with all interfaces. This fixes a potential issue with concurrent
dualband APs where the UUID needs to be same for PBC to work properly.
This can happen, e.g., when a P2P client connects to a P2P group
using the infrastructure WLAN interface instead of P2P group
interface. In that case, the P2P client may behave as if the GO
would be a P2P Manager WLAN AP.
For now, this applies to the test command that can be used to set
periodic NoA (p2p_set noa). The value are stored and periodic NoA
is enabled whenever there are no non-P2P STAs connected to the GO.
If CONFIG_WPS_STRICT is set, validate WPS IE(s) in management frames and
reject the frames if any of the mandatory attributes is missing or if an
included attribute uses an invalid value. In addition, verify that all
mandatory attributes are included and have valid values in the WSC
messages.
Advertize list of authorized enrollee MAC addresses in Beacon and
Probe Response frames and use these when selecting the AP. In order
to provide the list, the enrollee MAC address should be specified
whenever adding a new PIN. In addition, add UUID-R into
SetSelectedRegistrar action to make it potentially easier for an AP
to figure out which ER sent the action should there be multiple ERs
using the same IP address.
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).
