If an application initiates the Connect() operation and
that application has an agent registered, then that
application's agent will be called. Otherwise, the default
agent is called.
==40686== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==40686== at 0x5147037: sendmsg (in /usr/lib64/libc-2.24.so)
==40686== by 0x43957C: operate_cipher (cipher.c:354)
==40686== by 0x439C18: l_cipher_decrypt (cipher.c:415)
==40686== by 0x40FAB8: arc4_skip (crypto.c:181)
Initialize the skip buffer to 0s. This isn't strictly necessary, but
hides the above valgrind warning.
The aim of arc4 skip is simply to seed some data into the RC4 cipher so
it makes it harder for the attacker to decrypt. This 'initialization'
doesn't really care what data is fed.
CMD_DEAUTHENTICATE is not available for FullMAC based cards. We already
use CMD_CONNECT in the non-FT cases, which works on all cards. However,
for some reason we kept using CMD_DEAUTHENTICATE instead of CMD_DISCONNECT.
For FT (error) cases, keep using CMD_DEAUTHENTICATE.
Test that the AP interface and the station interface managed by iwd
can actually send and receive ethernet traffic when iwd is in the
connected state. Due to linux routing none of the high level utilities
like ping or arping can be easily used to test communication between
two interfaces of the same machine so use a method based on the
mac80211_hwsim/tools/hwsim_test.c utility in the wpa_supplicant tree
that uses a raw socket to inject unicast and broadcast frames.
Add this check in three tests of different security type connections
that simulate a single AP, and the two roaming tests with two APs.
Check that the station can't communicate with the other AP's interface.
Certain WiFi drivers do not support using CMD_SET_STATION (e.g.
mwifiex). It is not completely clear how such drivers handle the
AUTHORIZED state, but they don't seem to take it into account. So for
such drivers, ignore the -ENOTSUPP error return from CMD_SET_STATION.
These flags are documented in RFC2863 and kernel's
Documentation/networking/operstates.txt. Operstate doesn't have any
siginificant effect on normal connectivity or on our autotests because
it is not used by the kernel except in some rare cases but it is
supposed to affect some userspace daemons that watch for RTM_NEWLINK
events, so I believe we *should* set them according to this
documentation. Changes:
* There's no point setting link_mode or operstate of the netdev when
we're bringing the admin state DOWN as that overrides operstate.
* Instead of numerical values for link_mode use the if.h defines.
* Set IF_OPER_UP when association succeeds also in the Fast Transition
case. The driver will have set carrier off and then on so the
operstate should be IF_OPER_DORMANT at this point and needs to be
reset to UP.
Allow registering and unregistering agent object to receive RSSI level
notifications. The methods are similar to the ones related to the
password agent, including a Release method for the agent.
Add an methods and an event using the new
NL80211_EXT_FEATURE_CQM_RSSI_LIST kernel feature to request RSSI
monitoring with notifications only when RSSI moves from one of the N
intervals requested to another.
device.c will call netdev_set_rssi_report_levels to request
NETDEV_EVENT_RSSI_LEVEL_NOTIFY events every time the RSSI level changes,
level meaning one of the intervals delimited by the threshold values
passed as argument. Inside the event handler it can call
netdev_get_rssi_level to read the new level.
There's no fallback to periodic polling implemented in this patch for
the case of older kernels and/or the driver not supporting
NL80211_EXT_FEATURE_CQM_RSSI_LIST.
Use the same machine type regardless of has_virt: q35 with accelerators
list set to kvm:tcg, this will use KVM if available and fall back to TCG
if not available so there's no point checking has_virt. We can't
reliably know if KVM is usable anyway: even if the CPU has the
virtualization extensions, the support might not be enabled in the QEMU
build or there may be no kernel module or we may be calling a different
qemu executable than the one supporting KVM.
Set CPU type to "host" if KVM available and "max" otherwise because
"host" is not supported without KVM. We actually want to emulate the
host CPU as closely as possible so that host executables can run even if
optimized for the specific CPU. "max" seems to be the new way (since
Feb only) to request "host" cpu without KVM. It seems that the idea is
for "max" to become same as "host" if KVM is enabled so at some point we
will want to switch to using "max" in both cases.
The "level=9" flag seems to have been an error, there's no CPU with
cpuid max level of 9 and I can't see the purpose of setting the cpuid
level other than the host cpu's level.
-enable-kvm is redundant with accel=kvm:tcg in current qemu.
Again I'm not able to test this patch on a cpu that would be affected
by it but I hope this fixes some situations which are currently broken
anyway.
Update check_virtualization to check for the SVM on x86, KVM supports
both VMX and SVM. Fix the clobber list of the VMX check: memory is not
clobbered while ebx and edx are (ecx is already marked as output).
I'm not able to test this patch on a cpu that would be affected by it
but I don't think test-runner has been tested on those cpus yet.
==27901== Conditional jump or move depends on uninitialised value(s)
==27901== at 0x41157A: handshake_util_find_pmkid_kde
(handshake.c:537)
==27901== by 0x40E03A: eapol_handle_ptk_1_of_4 (eapol.c:852)
==27901== by 0x40F3CD: eapol_key_handle (eapol.c:1417)
==27901== by 0x40F955: eapol_rx_packet (eapol.c:1607)
==27901== by 0x410321: __eapol_rx_packet (eapol.c:1915)
