src/mpdu.c: In function ‘mpdu_validate’:
src/mpdu.c:180:9: error: ‘mmpdu’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
mmpdu = (const struct mmpdu_header *) mmpdu;
^
Refactor management frame structures to take into account optional
presence of some parts of the header:
* drop the single structure for management header and body since
the body offset is variable.
* add mmpdu_get_body to locate the start of frame body.
* drop the union of different management frame type bodies.
* prefix names specific to management frames with "mmpdu" instead
of "mpdu" including any enums based on 802.11-2012 section 8.4.
* move the FC field to the mmpdu_header structure.
This EAP method uses nearly all the logic from EAP-AKA. The major
difference is it uses the new key derivation functions for AKA' as
well as the SHA256 MAC calculation.
EAP-AKA' uses SHA256 rather than SHA1 to generate the packet MAC's.
This updates the derive MAC API to take the EAP method type and
correctly use the right SHA variant to derive the MAC.
This is the core key generation code for the AKA' method which
follows RFC 5448. Two new functions are implemented, one for
deriving CK'/IK' and the other for deriving the encryption keys
using CK'/IK'.
If the kernel device driver or the kernel nl80211 version doesn't
support the new RSSI threshold list CQM monitoring, implement similar
logic in iwd with periodic polling. This is only active when an RSSI
agent is registered to receive the events. I tested this with the same
testRSSIAgent autotests that tests the driver-side rssi monitoring
except with all timeouts multiplied by ~20.
The AT_VERSION_LIST attribute length was not being properly
checked. The actual length check did not include possible padding
bytes, so align_len() was added to ensure it was padded properly.
The comment about the padding being included in the Master Key
generation was not correct (padding is NOT included), and was removed.
Function to allow netdev.c to explicitly tell eapol.c whether to expect
EAP / 4-Way handshake. This is to potentially make the code more
descriptive, until now we'd look at sm->handshake->ptk_complete to see
if a new PTK was needed.
A 4-Way handshake is required on association to an AP except after FT.
Modify netdev_get_iftype, which was until now unused, and add
netdev_set_iftype. Don't skip interfaces with types other than STATION
on startup, instead reset the type to STATION in device.c.
netdev_get_iftype is modified to use our own interface type enum to
avoid forcing users to include "nl80211.h".
Note that setting an interface UP and DOWN wouldn't generally reset the
iftype to STATION. Another process may still change the type while iwd
is running and iwd would not detect this as it would detect another
interface setting interface DOWN, not sure how far we want to go in
monitoring all of the properties this way.
If we're adding the BSS to the list only because it is the current BSS,
set the rank to 0 (lowest possible value) in case the list gets used in
the next Connect call.
Allow attempts to connect to a new AP using the Reassociation frame even
if netdev->operational is false. This is needed if we want to continue
an ongoing roam attempt after the original connection broke and will be
needed when we start using cached PMKSAs in the future.
Use beacon loss event to trigger a roam attempt in addition to the RSSI
monitoring. Due to the how well beacons are normally received compared
to data packets, a beacon loss indicates a serious problem with the
connection so act as soon as a first beacon loss event is seen.
Avoid roaming methods that involve the current AP: preauthentication,
neighbor report request and FT-over-the-DS (not supported)
There are situations including after beacon loss and during FT where the
cfg80211 will detect we're now disconnected (in some cases will send a
Deauthenticate frame too) and generate this event, or the driver may do
this. For example in ieee80211_report_disconnect in net/mac80211/mlme.c
will (through cfg80211) generate a CMD_DEAUTHENTICATE followed by a
CMD_DISCONNECT.
The kernel doesn't reset the netdev's state to disconnected when it
sends us a beacon loss event so we can't either unless we automatically
send a disconnect command to the kernel.
It seems the handling of beacon loss depends on the driver. For example
in mac80211 only after N beacon loss events (default 7) a probe request is
sent to the AP and a deauthenticate packet is sent if no probe reply is
receiver within T (default 500ms).
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.
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.
