In network_autoconnect, when the network was SECURITY_8021X there was no
check (for SECURITY_PSK) before calling network_load_psk. Since the
provisioning file was for an 8021x network neither PreSharedKey or
Passphrase existed so this would always fail. This fixes the 8021x failure
in testConnectAutoconnect.
During the handshake setup, if security != SECURITY_PSK then 8021x settings
would get set in the handshake object. This didn't appear to break anything
(e.g. Open/WEP) but its better to explicitly check that we are setting up
an 8021x network.
Check for HAVE_EXECINFO_H for all __iwd_backtrace_init usages.
Fixes:
src/main.o: In function `main':
main.c:(.text.startup+0x798): undefined reference to `__iwd_backtrace_init'
collect2: error: ld returned 1 exit status
A sorted list of hidden network BSSs observed in the recent scan
is kept for the informational purposes of the clients. In addition,
it has deprecated the usage of seen_hidden_networks variable.
Refactor the network->psk and network->passphrase loading and saving
logic to not require the PreSharedKey entry in the psk config file and
to generate network->psk lazily on request. Still cache the computed
PSK in memory and in the .psk file to avoid recomputing it which uses
many syscalls. While there update the ask_psk variable to
ask_passphrase because we're specifically asking for the passphrase.
According to the specification, Supported rates IE is supposed
to have a maximum length of eight rate bytes. In the wild an
Access Point is found to add 12 bytes of data instead of placing
excess rate bytes in an Extended Rates IE.
BSS: len 480
BSSID 44:39:C4:XX:XX:XX
Probe Response: true
TSF: 0 (0x0000000000000000)
IEs: len 188
...
Supported rates:
1.0(B) 2.0(B) 5.5(B) 6.0(B) 9.0 11.0(B) 12.0(B) 18.0 Mbit/s
24.0(B) 36.0 48.0 54.0 Mbit/s
82 84 8b 8c 12 96 98 24 b0 48 60 6c .......$.H`l
DSSS parameter set: channel 3
03
...
Any following IEs decode nicely, thus it seems that we can relax
Supported Rates IE length handling to support this thermostat.
After moving AP EAPoL code into eapol.c there were a few functions that
no longer needed to be public API's. These were changed to static's and
the header definition was removed.
Set an upper limit on a fragmented EAP-TLS request size similar to how
we do it in EAP-TTLS. While there make the code more similar to the
EAP-TTLS flag processing to keep them closer in sync. Note that the
spec suggests a 64KB limit but it's not clear if that is for the TLS
record or EAP request although it takes into account the whole TLS
negotiation so it might be good for both.
Some of the TTLS server implementations set the L flag in the fragment
packets other than the first one. To stay interoperable with such devices,
iwd is relaxing the L bit check.
Switch EAP-MD5 to use the common password setting key nomenclature.
The key name has been changed from PREFIX-MD5-Secret to PREFIX-Password.
Note: The old key name is supported.
In addition, this patch adds an ability to request Identity and/or
Password from user.
Adhoc was not waiting for BOTH handshakes to complete before adding the
new peer to the ConnectedPeers property. Actually waiting for the gtk/igtk
(in a previous commit) helps with this, but adhoc also needed to keep track
of which handshakes had completed, and only add the peer once BOTH were done.
This required a small change in netdev, where we memcmp the addresses from
both handshakes and only set the PTK on one.
Currently, netdev triggers the HANDSHAKE_COMPLETE event after completing
the SET_STATION (after setting the pairwise key). Depending on the timing
this may happen before the GTK/IGTK are set which will result in group
traffic not working initially (the GTK/IGTK would still get set, but group
traffic would not work immediately after DBus said you were connected, this
mainly poses a problem with autotests).
In order to fix this, several flags were added in netdev_handshake_state:
ptk_installed, gtk_installed, igtk_installed, and completed. Each of these
flags are set true when their respective keys are set, and in each key
callback we try to trigger the handshake complete event (assuming all the
flags are true). Initially the gtk/igtk flags are set to true, for reasons
explained below.
In the WPA2 case, all the key setter functions are called sequentially from
eapol. With this change, the PTK is now set AFTER the gtk/igtk. This is
because the gtk/igtk are optional and only set if group traffic is allowed.
If the gtk/igtk are not used, we set the PTK and can immediately trigger the
handshake complete event (since gtk_installed/igtk_installed are initialized
as true). When the gtk/igtk are being set, we immediately set their flags to
false and wait for their callbacks in addition to the PTK callback. Doing it
this way handles both group traffic and non group traffic paths.
WPA1 throws a wrench into this since the group keys are obtained in a
separate handshake. For this case a new flag was added to the handshake_state,
'wait_for_gtk'. This allows netdev to set the PTK after the initial 4-way,
but still wait for the gtk/igtk setters to get called before triggering the
handshake complete event. As a precaution, netdev sets a timeout that will
trigger if the gtk/igtk setters are never called. In this case we can still
complete the connection, but print a warning that group traffic will not be
allowed.
