Add the new set_key() parameter "key_flag" to provide more specific
description of what type of a key is being configured. This is needed to
be able to add support for "Extended Key ID for Individually Addressed
Frames" from IEEE Std 802.11-2016. In addition, this may be used to
replace the set_tx boolean eventually once all the driver wrappers have
moved to using the new key_flag.
The following flag are defined:
KEY_FLAG_MODIFY
Set when an already installed key must be updated.
So far the only use-case is changing RX/TX status of installed
keys. Must not be set when deleting a key.
KEY_FLAG_DEFAULT
Set when the key is also a default key. Must not be set when
deleting a key. (This is the replacement for set_tx.)
KEY_FLAG_RX
The key is valid for RX. Must not be set when deleting a key.
KEY_FLAG_TX
The key is valid for TX. Must not be set when deleting a key.
KEY_FLAG_GROUP
The key is a broadcast or group key.
KEY_FLAG_PAIRWISE
The key is a pairwise key.
KEY_FLAG_PMK
The key is a Pairwise Master Key (PMK).
Predefined and needed flag combinations so far are:
KEY_FLAG_GROUP_RX_TX
WEP key not used as default key (yet).
KEY_FLAG_GROUP_RX_TX_DEFAULT
Default WEP or WPA-NONE key.
KEY_FLAG_GROUP_RX
GTK key valid for RX only.
KEY_FLAG_GROUP_TX_DEFAULT
GTK key valid for TX only, immediately taking over TX.
KEY_FLAG_PAIRWISE_RX_TX
Pairwise key immediately becoming the active pairwise key.
KEY_FLAG_PAIRWISE_RX
Pairwise key not yet valid for TX. (Only usable with Extended Key ID
support.)
KEY_FLAG_PAIRWISE_RX_TX_MODIFY
Enable TX for a pairwise key installed with KEY_FLAG_PAIRWISE_RX.
KEY_FLAG_RX_TX
Not a valid standalone key type and can only used in combination
with other flags to mark a key for RX/TX.
This commit is not changing any functionality. It just adds the new
key_flag to all hostapd/wpa_supplicant set_key() functions without using
it, yet.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
This makes it more convenient to add, remove, and modify the parameters
without always having to update every single driver_*.c implementation
of this callback function.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a channel list changed event is received after a scan and before
selecting a BSS for connection, a BSS found on a now disabled channel
may get selected for connection. The connect request issued with the BSS
found on a disabled channel is rejected by cfg80211. Filter out the BSSs
found on disabled channels and select from the other BSSs found on
enabled channels to avoid unnecessary connection attempts that are bound
to fail.
The channel list information will be updated by the driver in cases like
country code update, disabling/enabling specific bands, etc. which can
occur between the scan and connection attempt.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This was previously done only in supplicant role, but a similar change
is needed for the authenticator role.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
In order to correctly encrypt rekeying frames, wpa_supplicant now checks
if a PTK is currently installed and sets the corresponding encrypt
option for tx_control_port().
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Linux kernel v4.17 added the ability to request sending control port
frames via nl80211 instead of a normal network socket. Doing this
provides the device driver with ordering information between the
control port frames and the installation of keys. This empowers it to
avoid race conditions between, for example, PTK replacement and the
sending of frame 4 of the 4-way rekeying handshake in an RSNA. The
key difference between a TX_CONTROL_PORT and normal socket send is
that the device driver will certainly get any EAPOL frames comprising
a 4-way handshake before it gets the key installation call
for the derived key. By flushing its TX buffers it can then ensure
that no pending EAPOL frames are inadvertently encrypted with a key
that the peer will not yet have installed.
Update the RSN supplicant system to use this new operation for sending
EAPOL-Key frames when the driver reports that this capability is
available; otherwise, fall back to a normal Ethernet TX.
I have tested this on DMG (11ad/ay) devices with an out-of-tree Linux
driver that does not use mac80211. Without this patch I consistently see
PTK rekeying fail if message 4/4 shares a stream with other in-flight
traffic. With this patch, and the driver updated to flush the relevant TX
queue before overwriting a PTK (knowing, now, that if there was a message
4/4 related to the key installation, it has already entered the driver
queue), rekeying is reliable.
There is still data loss surrounding key installation - this problem is
alluded to in IEEE Std 802.11-2016, 12.6.21, where extended Key ID
support is described as the eventual solution. This patch aims to at
least prevent rekeying from totally breaking the association, in a way
that works on kernels as far back as 4.17 (as per Alexander Wetzel
extended Key ID support should be possible on 5.2).
See http://lists.infradead.org/pipermail/hostap/2019-May/040089.html for
a little more context.
Signed-off-by: Brendan Jackman <brendan.jackman@bluwireless.co.uk>
Linux kernel v4.17 added the ability to request sending controlled port
frames (e.g., IEEE 802.1X controlled port EAPOL frames) via nl80211
instead of a normal network socket. Doing this provides the device
driver with ordering information between the control port frames and the
installation of keys. This empowers it to avoid race conditions between,
for example, PTK replacement and the sending of frame 4 of the 4-way
rekeying handshake in an RSNA. The key difference between the specific
control port and normal socket send is that the device driver will
certainly get any EAPOL frames comprising a 4-way handshake before it
gets the key installation call for the derived key. By flushing its TX
buffers it can then ensure that no pending EAPOL frames are
inadvertently encrypted with a key that the peer will not yet have
installed.
Add a CONTROL_PORT flag to the hostap driver API to report driver
capability for using a separate control port for EAPOL frames. This
operation is exactly like an Ethernet send except for the extra ordering
information it provides for device drivers. The nl80211 driver is
updated to support this operation when the device reports support for
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211. Also add a driver op
tx_control_port() for request a frame to be sent over the controlled
port.
Signed-off-by: Brendan Jackman <brendan.jackman@bluwireless.co.uk>
This variable is not specific to any P2P group interface and since it
was already used through global->p2p_init_wpa_s, it is cleaner to simply
move this to the global structure so that there is a single variable
instead of per-interface variables and need to pick the correct
interface.
Signed-off-by: Jouni Malinen <j@w1.fi>
The p2p_long_listen value was set on the control wpa_s struct while in a
lot of cases it operated on the p2p struct. Explicitly use the global
p2p_init_wpa_s struct in cases where we might not be operating on it
already.
Without this, simply starting a p2p_listen operation (e.g., using
wpa_cli) will not work properly. As the p2p_long_listen is set on the
controlling interface and wpas_p2p_cancel_remain_on_channel_cb() uses
p2p_init_wpa_s, it would not actually work. This results in
wpa_supplicant stopping listening after the maximum remain-on-channel
time passes when using a separate P2P Device interface.
Signed-off-by: Benjamin Berg <bberg@redhat.com>
sme_send_authentication() could fail before actually requesting the
driver to authenticate with a new AP. This could happen after
wpa_s->bssid got cleared even though in such a case, the old association
is maintained and still valid. This can result in unexpected behavior
since wpa_s->bssid would not match the current BSSID anymore.
Fix this by postponing clearing of wpa_s->bssid until the IE preparation
has been completed successfully.
Signed-off-by: Jouni Malinen <j@w1.fi>
send_frame() is documented to be used for "testing use only" and as
such, it should not have used here for a normal production
functionality. Replace this with use of send_mlme() which is already
used for sending Authentication frames in number of other cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
"SET driver_signal_override <BSSID> [<si_signal< <si_avg_signal>
<si_avg_beacon_signal> <si_noise> <scan_level>]" command can now be used
to request wpa_supplicant to override driver reported signal levels for
signal_poll and scan results. This can be used to test roaming behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
Fix a rebasing issue in the signal difference calculation. The older
patch was not updated to use the new cur_level local variable to get the
possibly updated signal level for the current BSS.
Fixes: a2c1bebd43 ("Improve roaming logic")
Signed-off-by: Jouni Malinen <j@w1.fi>
This is targeting the case of MAC address change for an association
which may require the interface to be set down for a short moment.
Previously, this ended up flushing the BSS table that wpa_supplicant
maintained and that resulted in having to scan again if the MAC address
was changed between the previous scan and the connection attempt. This
is unnecessary extra latency, so maintain the BSS entries for 5 seconds
(i.e., the same time that the old scan results are consider valid for a
new connection attempt) after an interface goes down.
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently, wpa_supplicant may roam too aggressively; the need_to_roam()
function will return early with a roaming decision if the difference in
signal level or throughput between the current and selected APs is
"sufficiently large." In particular, if the selected AP's estimated
throughput is more than 5k greater than the current AP's estimated
throughput, wpa_supplicant will decide to roam. Otherwise, if the
selected AP's signal level is less than the current AP's signal level,
or the selected AP's estimated throughput is at least 5k less than the
current AP's estimated throughput, wpa_supplicant will skip the roam.
These decisions are based only on one factor and can lead to poor
roaming choices (e.g., a roam should not happen if the selected AP's
estimated throughput meets the threshold but the current signal and
throughput are already good, whereas a roam should happen if the signal
is slightly worse but the estimated throughput is significantly better).
This change standardizes the roaming heuristic for signal strength
difference requirements and will hopefully improve user experience. The
change can be summarized as follows: based on the current signal level,
a certain roaming difficulty is assigned. Based on the selected AP's
estimated throughput relative to the current AP's estimated throughput,
the difficulty is adjusted up or down. If the difference in signal level
meets the threshold, a roam happens.
The hard-coded values were selected purely based on the previous version
of this function. They may eventually need to be fine-tuned for optimal
performance.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Do not prevent roam to a different BSS based only on the signal level
with the current BSS being higher than with the selected BSS. If the
estimated throughput is significantly higher (> 20%), allow roaming if
the following conditions are met.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the current SNR with the associated BSS is sufficiently good (better
than GREAT_SNR = 25), there is limited benefit from moving to another
BSS even if that BSS were to have a higher signal level. As such, skip
roaming based on the signal level difference between the selected BSS
from scan results and the current BSS for such cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Using average signal strength from the driver and hardcoded noise floor
does not look like an ideal design since there can be significant
differences in the driver-reported noise floor values. Furthermore, even
though the current noise floor is a snapshot from the driver, it is
common for drivers to use a noise floor value from a longer calibration
step and that should not prevent the driver provided value from being
used. This makes the comparisons of the signal strengths between the
current AP (signal_poll) and other APs (scan) more accurate.
As an example, test runs in home environment showed 5 dB difference
between the driver reported noise floor and the hardcoded value and this
could result in significant differences in estimated throughput
calculation.
Signed-off-by: Jouni Malinen <j@w1.fi>
This avoids a testing failure in the following test case sequence:
ap_ft_r1_key_expiration ap_open_external_assoc
Signed-off-by: Jouni Malinen <j@w1.fi>
TKIP countermeasures were already terminated on FLUSH, but the timer for
detecting two Michael MIC errors within 60 seconds was left behind. This
resulted in test case failures with following test sequence:
ap_cipher_tkip_countermeasures_sta ap_cipher_tkip_countermeasures_sta2
Signed-off-by: Jouni Malinen <j@w1.fi>
Some drivers (e.g. Marvell WiFi) don't report avg_beacon_signal, but
it's still useful to poll for the signal again when a roaming decision
needs to be made. Use si.avg_signal when si.avg_beacon_signal is not
available.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
We saw that on certain platforms in certain places we keep switching
between two APs and eventually get the same RSSI. Debugging showed that
we have a very big difference between the two antennas.
Ant A can hear AP A very well (-60) but AP B very bad (-80)
Ant B can hear AP B very well (-60) but AP A very bad (-80)
When the device associates to AP A, it'll learn to use Ant A. If the
device uses one single antenna to receive the scan results, it may hear
the AP it is currently associated to on the second antenna and get bad
results. Because of that, the wpa_supplicant will roam to the other AP
and the same scenario will repeat itself:
Association to AP A (Ant A reports -60).
Scan on Ant A: AP A: -60, AP B: -80
Scan on Ant B: AP A: -80, AP A: -60 ==> ROAM.
Association to AP B (Ant B reports -60)
Scan on Ant A: AP A: -60, AP B: -80 ==> ROAM
Etc...
Improve this by querying the signal level of the current AP using
drv_signal_poll() instead of relying on the signal level that we get
from the scan results. Also update the throughput estimate based on the
likely more accurate values for the current association.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This is a step towards allowing this functionality to update the scan
result -based values with the values from a signal poll for the current
BSS.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This is a step towards allowing these values to be determined based on
signal poll instead of scan results.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Do not disconnect on interface deinit when WoWLAN is enabled, so we can
boot the system with WoWLAN after S5 (poweroff).
Signed-off-by: Alfonso Sanchez-Beato <alfonso.sanchez-beato@canonical.com>
This can be used in the future to implement support for RNR and scanning
extensions using a shorter field for the SSID.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
When wpa_supplicant receives another new peer event before the first one
has been processed, it tries to add a station to the driver a second
time (which fails) and then tears down the station entry until another
event comes in.
Fix this by only adding a station to the driver if it didn't exist
already.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If hostapd or wpa_supplicant is started with both -s and -f command line
arguments, debug log ended up being written only into syslog and the log
file was left empty. Change this so that the log entries will be written
to both places. Either -s or -f (or both) results in debug log to stdout
being disabled which was already the case.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use LAST_ID of LIST_NETWORKS to load all the network entries iteratively
if there is large enough number of networks to not fit in a single
response.
Signed-off-by: Victor Ananyev <vindex10@gmail.com>
This allows starting point of the network list to be specified so that
the potentially long response can be fragmented into multiple fetch
operations.
Signed-off-by: Victor Ananyev <vindex10@gmail.com>
Field wpa_s->sme.ht_sec_chan keeps secondary channel for the 40 MHz
band. This field is used to prepare a list of channels for the STA OBSS
scan. Initially, the secondary channel is set to HT_SEC_CHAN_UNKNOWN.
Later on, in function wpa_obss_scan_freq_list() it is obtained from the
current BSS HT operation IE. However, the secondary channel information
is not updated after channel switch, which may lead to an incorrect list
of channels prepared for the STA OBSS scan.
Update ht_sec_chan according to the channel switch event data to fix
this.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
In the previous implementation connected STA performs OBSS scan
according to requests from its 20/40 MHz AP. However STA checks only 40
MHz intolerance subfield from HT Capabilities element in scan results.
Meanwhile, as per IEEE Std 802.11-2016, 11.16.12, STA should check
overlapping BSSs as well.
Note that all the required code to check overlapping BSSs did already
exist for AP mode since AP does those checks properly before operating
as 20/40 MHz BSS in the 2.4 GHz band. Use that existing code by replace
existing 40 MHz intolerance check in sme_proc_obss_scan() with the new
shared helper function check_bss_coex_40mhz().
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
This gives us the network device name in logging messages, which can be
helpful when having one wpa_supplicant process handle multiple devices.
Signed-off-by: Ben Greear <greearb@candelatech.com>
This allows BIP-GMAC-128, BIP-GMAC-256, or BIP-CMAC-256 to be used
instead of the previously hardcoded AES-128-CMAC as the group management
cipher when using mesh with PMF. For now, this can be configured by
setting a single group_mgmt value in the network block and doing that
consistently through all the STAs in the mesh.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous calculation of the buffer length did not take into account
the possibility of 32-octet GTK and IGTK values and it was also missing
something to cover the 16 octet keys that are supported now. Other
buffer elements were likely sufficient to cover all these cases, but
anyway, it is better to allocate sufficient size specifically for AMPE
to avoid issues in the future.
Signed-off-by: Jouni Malinen <j@w1.fi>
WPS_EVENT_CANCEL is added to indicate cancellation of a WPS operation
for any reason in hostapd/wpa_supplicant.
WPS_EVENT_PIN_ACTIVE is added to indicate when a PIN operation is
triggered in wpa_supplicant.
Signed-off-by: Veli Demirel <veli.demirel@airties.com>
Signed-off-by: Bilal Hatipoglu <bilal.hatipoglu@airties.com>
When the newly added "-r" parameter is used, both clis will try to
reconnect forever on connection lost until signalled (ctrl+c) or
terminated. This is useful only when used with -a to take action to
retrieve events or get status and the cli process stays even if
hostapd/wpa_supplicant daemons restart for some reason (e.g.,
configuration change).
Signed-off-by: Veli Demirel <veli.demirel@airties.com>
Signed-off-by: Bilal Hatipoglu <bilal.hatipoglu@airties.com>
This array had not been updated for years (since it was initially added)
and it was missing new network profile parameters that were not quoted
strings (but also not integers that could be set as integer types). Add
those missing non-quoted-strings to allow them to be set through the
DBus interface.
Signed-off-by: Jouni Malinen <j@w1.fi>
These parameters are global parameters, not network profile parameters,
and as such, do not below in dont_quote[] which is used to determine
whether a network profile parameter needs to be quoted.
Signed-off-by: Jouni Malinen <j@w1.fi>
These properties were in the wpas_dbus_bss_properties array when they
should have been in the wpas_dbus_interface_properties array. Move them
to the right place. This is the logical location for these properties
and it matches both the other parts of the implementation (e.g., being
in enum wpas_dbus_prop, not in enum wpas_dbus_bss_prop) and what
was originally documented for the interface in dbus.doxygen.
Fixes: 2bbad1c7c9 ("dbus: Export roam time, roam complete, and session length")
Fixes: 80d06d0ca9 ("dbus: Export BSS Transition Management status")
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
