Commit graph

4864 commits

Author SHA1 Message Date
Vamsi Krishna
75d0ec4702 P2P: Fix a possible buffer overflow in struct p2p_reg_class
Avoid adding more than P2P_MAX_REG_CLASSES operating classes or
P2P_MAX_REG_CLASS_CHANNELS channels while populating P2P channels. The
current limits on the operating classes or channels per operating class
could be hit in some case (mainly, with 6 GHz, but in theory, with a
2.4/5/60 GHz capable device as well).

If the local driver advertised a larger number of supported operarting
classes or channels per operating class, the construction of the struct
p2p_reg_class instances could have resulted in writing beyond the end of
the buffer and ending up corrupting memory around the struct p2p_config.
This could result in unexpected behavior in some other operations that
used corrupted memory, e.g., generation of a P2P Channel List failing
(with validation code stopping the process to avoid writing beyond the
end of the message buffer) due to not having sufficient buffer space for
the corrupted data.

This issue is triggered only based on information from the local driver
(mainly based on addition of support for 6 GHz band operating classes),
so the issue cannot be triggered based on received frames or any other
remote information.

The issue was introduced by commit d7c2c5c98c ("AP: Add initial
support for 6 GHz band") which added the operating class 131 which has
sufficiently large number of channels to go beyond the
P2P_MAX_REG_CLASS_CHANNELS limit.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-12 23:17:24 +02:00
Jouni Malinen
c304bddcf9 DPP: Stop Action frame sequence on DPP_STOP_LISTEN and PKEX failure
Previously it was possible for the PKEX/DPP exchange to terminate with
an error and the ongoing Action frame TX/RX offchannel operation not
getting terminated. This could leave the driver waiting on offchannel
until timeout and failing following operations before that timeout
happens. Fix this by explicitly stopping the Action frame sequence in
the driver in the previously missed cases.

This fixes a case that was showing up with the following test sequence
every now and then:
dpp_qr_code_chan_list_unicast dpp_pkex_test_fail dpp_enrollee_reject_config

dpp_pkex_test_fail was adding a large number of pending offchannel
operations and dpp_enrollee_reject_config could fail if those pending
operations were blocking new remain-on-channel or offchannel TX
operation for a sufficiently long time.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-11 07:09:47 +02:00
Jouni Malinen
c7cc80fbc8 DPP: Reset DPP_AUTH_INIT netrole back to STA by default
Previously DPP_AUTH_INIT command update wpa_s->dpp_netrole only if the
netrole parameter was included. This could leave AP or configurator
network in place for the next DPP_AUTH_INIT command. This would be
unexpected behavior, so reset wpa_s->dpp_netrole back to the
DPP_NETROLE_STA default if no explicit netrole parameter is included.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-11 06:33:24 +02:00
Veerendranath Jakkam
adf3de44ca Add check to consider band in enabling connection_vht flag
connection_vht flag was set to true when both Association Request and
Response frame IEs have VHT capability. Thus all devices that have
support for the vendor specific partial VHT support in the 2.4 GHz band
were also being reported as VHT capable. However, IEEE Std 802.11ac-2013
defines VHT STA to operate in frequency bands below 6 GHz excluding the
2.4 GHz band.

Do not set connection_vht when the operating band is 2.4 GHz. This
avoids reporting wifi_generation 5 on the 2.4 GHz band and reserves the
generation value 5 for full VHT as defined in the IEEE 802.11 standard.

Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
2020-02-11 05:19:16 +02:00
Matthew Wang
23dc196fde Check for FT support when selecting FT suites
A driver supports FT if it either supports SME or the
NL80211_CMD_UPDATE_FT_IES command. When selecting AKM suites,
wpa_supplicant currently doesn't take into account whether or not either
of those conditions are met. This can cause association failures, e.g.,
when an AP supports both WPA-EAP and FT-EAP but the driver doesn't
support FT (wpa_supplicant will decide to do FT-EAP since it is unaware
the driver doesn't support it). This change allows an FT suite to be
selected only when the driver also supports FT.

Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
2020-02-10 06:43:38 +02:00
Jouni Malinen
641d79f165 SAE: Special test mode sae_pwe=3 for looping with password identifier
The new sae_pwe=3 mode can be used to test non-compliant behavior with
SAE Password Identifiers. This can be used to force use of
hunting-and-pecking loop for PWE derivation when Password Identifier is
used. This is not allowed by the standard and as such, this
functionality is aimed at compliance testing.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-10 05:13:13 +02:00
Jouni Malinen
ca1cecc54d SAE: Verify that appropriate Status Code is used in SAE commit (SME)
Previous version accepted both 0 and 126 values in SAE commit message
from the AP. Explicitly check that the value the AP uses matches what
the STA started with to avoid unexpected cases.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-08 07:19:53 +02:00
Jouni Malinen
4dc3b70deb DPP: Try to negotiate different parameters if NFC handover fails
This is mainly for NFC testing purposes now since the own DPP parameters
are not yet updated.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-08 07:19:53 +02:00
Jouni Malinen
61c049da3d DPP: Allow local channel list to be set
The new dpp-nfc.py command line argument --chan can be used to replace
the local channel list default (81/1).

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-02-08 07:19:53 +02:00
Matthew Wang
fee28410de scan_est_throughput: Use ie_len instead of res->ie_len
Local variable should be used. This fixes an issue where IEs are
available only from a Beacon frame.

Fixes: ad06ac0b0 ("Move throughput estimation into a helper function")
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
2020-02-02 21:55:42 +02:00
Jouni Malinen
7d9e320054 DPP: Received Configurator backup processing
Add local Configurator instance for each received Configurator backup.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-31 23:16:05 +02:00
Jouni Malinen
312eac1d1e DPP: Add ASN.1 support into build
This will be needed in following patches to process DPPEnvelopedData.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-31 23:16:05 +02:00
Jouni Malinen
703c2b6457 DPP: Example script for NFC bootstrapping method
This Python script is an example on how nfcpy can be used to drive an
NFC Device to perform DPP bootstrapping operations over DPP (tag with
NFC URI and negotiated connection handover).

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-27 21:58:45 +02:00
Jouni Malinen
5e287724ee DPP: NFC negotiated connection handover
Add new control interface commands "DPP_NFC_HANDOVER_REQ own=<id>
uri=<URI>" and "DPP_NFC_HANDOVER_SEL own=<id> uri=<URI>" to support NFC
negotiated connection handover. These commands are used to report a DPP
URI received from a peer NFC Device in Handover Request and Handover
Select messages. The commands return peer bootstrapping information ID
or FAIL on failure. The returned ID is used similarly to any other
bootstrapping information to initiate DPP authentication.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-27 20:36:09 +02:00
Jouni Malinen
8b138d2826 OWE: PTK derivation workaround in STA mode
Initial OWE implementation used SHA256 when deriving the PTK for all OWE
groups. This was supposed to change to SHA384 for group 20 and SHA512
for group 21. The new owe_ptk_workaround=1 network parameter can be used
to enable older behavior mainly for testing purposes. There is no impact
to group 19 behavior, but if enabled, this will make group 20 and 21
cases use SHA256-based PTK derivation which will not work with the
updated OWE implementation on the AP side.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-24 00:47:41 +02:00
Vamsi Krishna
d0e116f61f Enhance get_mode() to return correct hw_mode with 6 GHz support
The 5 GHz channels are stored in one hw_features set with mode
HOSTAPD_MODE_IEEE80211A while the 6 GHz channels will need to be stored
in a separate hw_features set (but with same mode
HOSTAPD_MODE_IEEE80211A) due to possibility of different HT/VHT/HE
capabilities being available between the 5 GHz and 6 GHz bands.

Iterate through all hw_features sets and check and match the band of
channel supported by the hw_features set while getting the hw_features
set in get_mode(). This allows both the 5 GHz and 6 GHz channels to be
found and correct capabilities to be used in cases where the driver
reports different capability values between 5 and 6 GHz channels.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-23 15:48:51 +02:00
Chaitanya Tata
4658eb77d6 Remove deprecated text for ap_scan=0
Users might be tempted to try ap_scan=0 for offloading scan,
ap_selection and, WPA to driver. Update the text to reflect that this is
deprecated.

Jouni confirmed deprecation in
https://www.spinics.net/lists/hostap/msg06482.html

Signed-off-by: Chaitanya Tata <chaitanya.tata@bluwireless.com>
2020-01-21 18:17:07 +02:00
Jouni Malinen
5e32fb0170 SAE: Use Anti-Clogging Token Container element with H2E
IEEE P802.11-REVmd was modified to use a container IE for anti-clogging
token whenver H2E is used so that parsing of the SAE Authentication
frames can be simplified.

See this document for more details of the approved changes:
https://mentor.ieee.org/802.11/dcn/19/11-19-2154-02-000m-sae-anti-clogging-token.docx

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-21 13:13:56 +02:00
Jouni Malinen
e36a5894d0 SAE: Use H2E whenever Password Identifier is used
IEEE P802.11-REVmd was modified to require H2E to be used whenever
Password Identifier is used with SAE.

See this document for more details of the approved changes:
https://mentor.ieee.org/802.11/dcn/19/11-19-2154-02-000m-sae-anti-clogging-token.docx

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-21 13:13:56 +02:00
Jouni Malinen
29dd0b3164 SAE H2E: Check H2E-only BSS membership selector only if SAE is enabled
This BSS membership selector has impact only for SAE functionality, so
ignore it when configured not to use SAE. This allows WPA-PSK connection
to and AP that advertises WPA-PSK and SAE while requiring H2E for SAE.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-20 21:17:28 +02:00
Jouni Malinen
dd530b8739 Silence compiler warning with CONFIG_NO_ROAMING=y
Comment out unused static functions if CONFIG_NO_ROAMING is defined.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2020-01-09 12:40:17 +02:00
Alexander Wetzel
a919a26035 Introduce and add key_flag
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>
2020-01-09 12:38:36 +02:00
Jouni Malinen
f822546451 driver: Move set_key() parameters into a struct
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>
2020-01-09 00:48:57 +02:00
Vamsi Krishna
33c8a10498 Do not select APs found on disabled channels for connection
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>
2020-01-08 16:19:47 +02:00
Markus Theil
8296ee1805 RSN IBSS: Fix EAPOL TX using control port
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>
2020-01-06 22:33:45 +02:00
Markus Theil
a79ed06871 Add no_encrypt flag for control port TX
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>
2020-01-05 20:34:50 +02:00
Brendan Jackman
144314eaa7 wpa_supplicant: Send EAPOL frames over nl80211 where available
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>
2020-01-05 20:34:15 +02:00
Brendan Jackman
8759e9116a nl80211: Control port over nl80211 helpers
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>
2020-01-05 19:43:52 +02:00
Jouni Malinen
b7bb2c0204 P2P: Move p2p_long_listen into struct wpa_global
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>
2020-01-04 23:11:28 +02:00
Benjamin Berg
9ad3c12dd1 P2P: Always use global p2p_long_listen
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>
2020-01-04 23:07:31 +02:00
Jouni Malinen
af670cb418 SME: Postpone current BSSID clearing until IEs are prepared
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>
2020-01-03 18:06:01 +02:00
Jouni Malinen
665a3007fb driver: Add no_encrypt argument to send_mlme()
This is in preparation of being able to remove the separate send_frame()
callback.

Signed-off-by: Jouni Malinen <j@w1.fi>
2020-01-03 13:53:32 +02:00
Jouni Malinen
9474654752 IBSS RSN: Use send_mlme() instead of send_frame() for Authentication frames
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>
2020-01-03 12:21:36 +02:00
Jouni Malinen
6c57019376 Test functionality to override driver reported signal levels
"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>
2020-01-02 20:34:39 +02:00
Jouni Malinen
c8eb7fe66c Fix signal_poll based roaming skip
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>
2020-01-02 20:34:39 +02:00
Roy Marples
a8b00423ea BSD: Use struct ip rather than struct iphdr
As we define __FAVOR_BSD use the BSD IP header.
Compile tested on NetBSD, DragonFlyBSD, and Linux.

Signed-off-by: Roy Marples <roy@marples.name>
2020-01-02 19:17:10 +02:00
Jouni Malinen
ad2f096609 Maintain BSS entries for 5 seconds after interface is disabled
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>
2020-01-02 12:58:58 +02:00
Jouni Malinen
988f14448a Indicated if the selected BSS is the current BSS
This makes scan result processing a bit more readable in debug log.

Signed-off-by: Jouni Malinen <j@w1.fi>
2020-01-01 17:55:26 +02:00
Jouni Malinen
a8ad9c31db Make min_diff determination from cur_level more readable
This handles both the dBm and unspecified unit cases.

Signed-off-by: Jouni Malinen <j@w1.fi>
2020-01-01 17:46:03 +02:00
Jouni Malinen
41f72d7356 Use sel_est consistently with cur_sel in wpa_supplicant_need_to_roam()
This makes the code a bit easier to read.

Signed-off-by: Jouni Malinen <j@w1.fi>
2020-01-01 17:37:58 +02:00
Matthew Wang
a2c1bebd43 Improve roaming logic
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>
2020-01-01 17:33:51 +02:00
Jouni Malinen
9c8d550b77 Allow roam to lower signal level if throughput benefit is significant
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>
2020-01-01 17:09:18 +02:00
Jouni Malinen
9fafefb9e5 Skip roaming based on signal level difference if current SNR is good
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>
2020-01-01 16:56:40 +02:00
Jouni Malinen
f4f7600adf Use signal_poll noise information for roaming, if available
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>
2020-01-01 13:38:11 +02:00
Jouni Malinen
f97baef254 Clear SME auth_alg on FLUSH
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>
2020-01-01 12:33:57 +02:00
Jouni Malinen
0d1d1f0d21 Clear last Michael MIC error timer on FLUSH
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>
2020-01-01 12:23:25 +02:00
Matthew Wang
69ccc557d8 wpa_supplicant: Fall back to avg_signal in roaming decision
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>
2019-12-31 00:23:42 +02:00
Emmanuel Grumbach
7e7b23e229 Update throughput estimate for the current BSS based on signal poll
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>
2019-12-31 00:21:37 +02:00
Emmanuel Grumbach
ad06ac0b04 Move throughput estimation into a helper function
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>
2019-12-31 00:17:04 +02:00
Emmanuel Grumbach
ef1a45f28a Move scan/roaming related defines to a header file
This is a step towards allowing these values to be used in both scan.c
and events.c.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2019-12-31 00:04:33 +02:00