I saw a case where the kernel's cfg80211 rejected hostapd's attempt to
send a neighbor report response because nl80211 flagged the frame as
offchannel-OK, but kernel rejects because channel was 100 (DFS) and so
kernel failed thinking it was constrained by DFS/CAC requirements that
do not allow the operating channel to be left (at least in FCC).
Don't set the packet as off-channel OK if we are transmitting on the
current operating channel of an AP to avoid such issues with
transmission of Action frames.
Signed-off-by: Ben Greear <greearb@candelatech.com>
This functionality has been available in mac80211_hwsim for years, so
there is no need to maintain this old workaround.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is to match the NL80211_CMD_ACTION renaming to NL80211_CMD_FRAME
that happened long time ago. This command can be used with any IEEE
802.11 frame and it should not be implied to be limited to Action
frames.
Signed-off-by: Jouni Malinen <j@w1.fi>
Replace a separate cookie_out pointer argument with save_cookie boolean
since drv->send_action_cookie is the only longer term storage place for
the cookies. Merge all nl80211_send_frame_cmd() callers within
wpa_driver_nl80211_send_mlme() to use a single shared call to simplify
the function.
Signed-off-by: Jouni Malinen <j@w1.fi>
Merge this function into wpa_driver_nl80211_send_mlme() that is now the
only caller for the previously shared helper function. This is a step
towards cleaning up the overly complex code path for sending Management
frames.
Signed-off-by: Jouni Malinen <j@w1.fi>
All the previous users have now been converted to using send_mlme() so
this unused send_frame() callback can be removed.
Signed-off-by: Jouni Malinen <j@w1.fi>
Since send_mlme() now has support for the no_encrypt argument it is
possible to get rid of the remaining send_frame() uses.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows send_mlme() to be used to replace send_frame() for the test
cases where unencrypted Deauthentication/Disassociation frames need to
be sent out even when using PMF for the association. This is currently
supported only when monitor interface is used for AP mode management
frames.
Signed-off-by: Jouni Malinen <j@w1.fi>
Merge hostapd_drv_send_mlme_csa() functionality into
hostapd_drv_send_mlme() to get a single driver ops handler function for
hostapd. In addition, add a new no_encrypt parameter in preparation for
functionality that is needed to get rid of the separate send_frame()
driver op.
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 Deauthentication frames in other cases.
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>
Call nl80211_send_monitor() directly instead of going through
wpa_driver_nl80211_send_frame() for the case where monitor interface is
used for AP mode management purposes. drv->use_monitor has to be 1 in
this code path, so wpa_driver_nl80211_send_frame() was calling
nl80211_send_monitor() unconditionally for this code path and that extra
function call can be removed here to simplify the implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
Netlink dump message may be interrupted if an internal inconsistency is
detected in the kernel code. This can happen, e.g., if a Beacon frame
from the current AP is received while NL80211_CMD_GET_SCAN is used to
fetch scan results. Previously, such cases would end up not reporting an
error and that could result in processing partial data.
Modify this by detecting this special interruption case and converting
it to an error. For the NL80211_CMD_GET_SCAN, try again up to 10 times
to get the full response. For other commands (which are not yet known to
fail in similar manner frequently), report an error to the caller.
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>
libnl functions return a library specific error value in libnl 2.0 and
newer. errno is not necessarily valid in all error cases and strerror()
for the returned value is not valid either.
Use nl_geterror() to get the correct error string from the returned
error code.
Signed-off-by: Jouni Malinen <j@w1.fi>
libnl functions return a library specific error value. errno is not
necessarily valid in all error cases and strerror() for the returned
value is not valid either.
Use nl_geterror() to get the correct error string from the returned
error code.
Signed-off-by: Jouni Malinen <j@w1.fi>
This simplifies code by not having to maintain and come up with new
backwards compatibility wrappers for a library release from 12 years
ago.
Signed-off-by: Jouni Malinen <j@w1.fi>
These are certainly not error conditions, but normal cases for starting
up. Drop the message from ERROR to DEBUG.
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>
Add PMKSA candidates from scan results only if they advertise an AKMP
that is used with RSN pre-authentication. Previously, candidates were
added but then ignored later if the AKMP was not suitable.
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>
sae_pwe=1 could be left configured when exiting this test case since
sigma_dut does not guarantee the default value to be restored. This
could result in test case failures, e.g., in the following sequence:
sigma_dut_sae_h2e_rsnxe_mismatch sae_pwe_h2e_only_ap_sta_forcing_loop
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit changes the failover behavior of RADIUS client. Commit
27ebadccfb ("RADIUS client: Cease endless retry for message for
multiple servers") changed the retry logic, causing RADIUS client to
wait RADIUS_CLIENT_NUM_FAILOVER + 1 timeouts before failing over the
first time. Prior to that commit, RADIUS client would wait
RADIUS_CLIENT_NUM_FAILOVER timeouts before each failover. This was
caused by moving the entry->attempts > RADIUS_CLIENT_NUM_FAILOVER
comparison to before the retry attempt, where entry->attempts is
incremented.
The commit in question set entry->attempts in radius_change_server to 1
instead of 0, so RADIUS client would still only wait
RADIUS_CLIENT_NUM_FAILOVER timeouts for subsequent failovers, the same
as the original behavior.
This commit changes the comparison so the initial failover now happens
after waiting RADIUS_CLIENT_NUM_FAILOVER timeouts, as it did originally.
It also changes the RADIUS_CLIENT_MAX_FAILOVER comparison to prevent an
additional attempt to the primary server after the final failover.
Signed-off-by: Ethan Everett <ethan.everett@meraki.net>
It looks like this test case can start showing failures with a change in
the retransmission limit behavior for a server change. Check for
retransmissions every second instead of only at the end of the four
second wait to avoid this.
Signed-off-by: Jouni Malinen <j@w1.fi>
