This is meant to reset the EAP state back to its original state without
affecting any state variables obtained through load_settings. This can
be useful for EAP Reauthentication triggered by the AP.
Instead use '-d' command line option. This option uses an optional
argument. Without an argument, '*' is assumed. Otherwise you can
specify a glob string to match. Any debug output that matches the glob
string will be printed. e.g.:
src/iwd -d '*eap*'
Some EAP servers might try to send us packets after the EAP connection
has been established. When EAP succeeds we destroy the EAP object. If
a new EAP request arrives we create a temporary EAP object to handle the
request (most likely to NAK it). However, if the packet is not destined
to a particular method (e.g. it is a notification) the current logic can
result in a crash.
src/netdev.c:netdev_set_gtk() 3
==4300== Invalid read of size 8
==4300== at 0x14204B: __eap_handle_request (eap.c:203)
==4300== by 0x142339: eap_rx_packet (eap.c:287)
==4300== by 0x12AEF9: eapol_rx_packet (eapol.c:1622)
==4300== by 0x12BBBC: __eapol_rx_packet (eapol.c:2018)
==4300== by 0x116D1E: netdev_pae_read (netdev.c:3121)
==4300== by 0x16672B: io_callback (io.c:123)
==4300== by 0x165239: l_main_iterate (main.c:376)
==4300== by 0x16537D: l_main_run (main.c:423)
==4300== by 0x10F95C: main (main.c:447)
==4300== Address 0x30 is not stack'd, malloc'd or (recently) free'd
==4300==
When the server sends an identity prompt or a notification, we were
trying to print from our local buffer, not from the actual packet. The
relevant valgrind trace is:
src/netdev.c:netdev_mlme_notify() MLME notification 64
==4300== Conditional jump or move depends on uninitialised value(s)
==4300== at 0x4C3006E: strnlen (vg_replace_strmem.c:425)
==4300== by 0x508C513: vfprintf (vfprintf.c:1643)
==4300== by 0x508EB75: buffered_vfprintf (vfprintf.c:2329)
==4300== by 0x508C1A1: vfprintf (vfprintf.c:1301)
==4300== by 0x167051: log_stderr (log.c:145)
==4300== by 0x16756E: l_log_with_location (log.c:293)
==4300== by 0x142173: __eap_handle_request (eap.c:235)
==4300== by 0x142339: eap_rx_packet (eap.c:287)
==4300== by 0x12AEF9: eapol_rx_packet (eapol.c:1622)
==4300== by 0x12BBBC: __eapol_rx_packet (eapol.c:2018)
==4300== by 0x116D1E: netdev_pae_read (netdev.c:3121)
==4300== by 0x16672B: io_callback (io.c:123)
==4300==
EAP identity prompt: ""
GLIBC is not necessarily the only library that provides execinfo.
With libexecinfo execinfo can be used also in other Libraries.
The patch lets the configure check the existence of the header
and the libexecinfo Library and uses them if avaible.
(also fixes compilation if execinfo is not avaible)
iwd was auto-connecting to the open networks despite having
Autoconnect=false flag set in the network configuration file.
This patch enables iwd to load the configuration files for the
open networks during the auto-connect attempt to take advantage
of the Autoconnect flag.
EAP-PWD was hard coded to only work on LE architectures. This
adds 2 conversion functions to go from network byte order (BE)
to any native architecture, and vise versa.
The file, src/ecc.c was taken from the bluez project:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/shared/ecc.c
There were minor changes made, e.g. changing some functions to globals
for access in EAP-PWD as well as removing some unneeded code. There was
also some code appended which allows for point addition, modulus inverse
as well as a function to compute a Y value given an X.
If Control Port over NL80211 is not supported, open up a PAE socket and
stuff it into an l_io on the netdev object. Install a read handler on
the l_io and call __eapol_rx_packet as needed.
With the introduction of Control Port Over NL80211 feature, the
transport details need to be moved out of eapol and into netdev.c.
Whether a given WiFi hardware supports transfer of Control Port packets
over NL80211 is Wiphy and kernel version related, so the transport
decisions need to be made elsewhere.
On connect add any secrets we've received through the agent to the
l_settings objects which the EAP methods will process in load_settings.
The settings object is modified but is never written to storage. If
this was to change because some settings need to be saved to storage,
a new l_settings object might be needed with the union of the settings
from the file and the secrets so as to avoid saving the sensitive data.
These EAP methods do not store the identity inside the settings file
since it is obtained from the SIM card, then provided to IWD via
get_identity method. If the get_identity method is implemented, do
not fail the settings check when EAP-Identity is missing.
Use eap_check_settings directly from network.c before we start the
connection attempt at netdev.c level, to obtain all of the required
passwords/passphrases through the agent. This is in network.c because
here we can decide the policies for whether to call the agent in
autoconnect or only if we had a request from the user, also whether we
want to save any of that for later re-use (either password data or
kernel-side key serial), etc.
In this patch we save the credentials for the lifetime of the network
object in memory, and we skip the network if it requires any passphrases
we don't have while in autoconnect, same as with PSK networks where the
PSK isn't given in the settings. Note that NetworkManager does pop up
the password window for PSK or EAP passwords even in autoconnect.
If EAP needs multiple passwords we will call the agent sequentially for
each.
Confirm that the PEM file paths that we'll be passing to the l_tls
object are loading Ok and request/validate the private key passphrase
if needed. Then also call eap_check_settings to validate the inner
method's settings.
Confirm that the PEM file paths that we'll be passing to the l_tls
object are loading Ok and request/validate the private key passphrase
if needed. Then also call eap_check_settings to validate the inner
method's settings.
With the goal of requesting the required passwords/passphrases, such as
the TLS private key passphrase, from the agent, add a static method
eap_check_settings to validate the settings and calculate what passwords
are needed for those settings, if any. This is separate from
eap_load_settings because that can only be called later, once we've
got an eap state machine object. We need to get all the needed EAP
credentials from the user before we even start connecting.
While we do this, we also validate the settings and output any error
messages through l_error (this could be changed so the messages go
somewhere else in the future), so I removed the error messages from
eap_load_settings and that method now assumes that eap_check_settings
has been called before.
eap_check_settings calls the appropriate method's .check_settings method
if the settings are complete enough to contain the method name. The
policy is that any data can be provided inside the l_settings object
(from the network provisioning/config file), but some of the more
sensitive fields, like private key passwords, can be optionally omitted
and then the UI will ask for them and iwd will be careful with
caching them.
Within struct eap_secret_info, "id" is mainly for the EAP method to
locate the info in the list. "value" is the actual value returned
by agent. "parameter" is an optional string to be passed to the agent.
For a private key passphrase it may be the path to the key file, for a
password it may be the username for which the password is requested.
In agent_receive_reply we first call the callback for the pending
request (agent_finalize_pending) then try to send the next request
in the queue. Check that the next request has not been sent already
which could happen if it has been just queued by the callback.
The difference in the handlers was that in the
NETDEV_EVENT_DISCONNECT_BY_AP case we would make sure to reply
to a pending dbus Connect call. We also need to do that for
NETDEV_EVENT_DISCONNECT_BY_SME. This happens if another process
sends an nl80211 disconnect command while we're connecting.
The eapol handshake timeout can now be configured in main.conf
(/etc/iwd/main.conf) using the key eapol_handshake_timeout. This
allows the user to configure a long timeout if debugging.
After an EAP exchange rsn_info would be uninitialized and in the FT case
we'd use it to generate the step 2 IEs which would cause an RSNE
mismatch during FT handshake.
Until now we'd save the second 32 bytes of the MSK as the PMK and use
that for the PMK-R0 as well as the PMKID calculation. The PMKID
actually uses the first 32 bytes of the PMK while the PMK-R0's XXKey
input maps to the second 32 bytes. Add a pmk_len parameter to
handshake_state_set_pmk to handle that. Update the eapol_eap_results_cb
802.11 quotes to the 2016 version.
handshake_state_install_ptk triggers a call to
netdev_set_pairwise_key_cb which calls netdev_connect_ok, so don't call
netdev_connect_ok after handshake_state_install_ptk. This doesn't fix
any specific problem though.
If the request being cancelled by agent_request_cancel has already been
sent over dbus we need to reset pending_id, the timeout, call l_dbus_cancel
to avoid the agent_receive_reply callback (and crash) and perhaps start
the next request. Alternatively we could only reset the callback and not
free the request, then wait until the agent method to return before starting
the next request.
Move the cancelling of the eapol timeout from the end of step 1 to
step 3 to guard the whole handshake. At the end of step 1 stop the
EAPOL-Start timeout for the case of 802.1X authentication + a cached
PMKSA (not used yet.)
Some APs respond to Neighbor Report Requests with neighbor reports that
have a zero operating class value and a non-zero channel number. This
does not mean that the channel is in the same band that the reporting
AP operates in. Try to guess the band that the channel refers to out of
2.4 and 5GHz -- the bands supported by those APs.
wpa_supplicant also has this workaround in place.
SA Query procedure is used when an unprotected disassociate frame
is received (with frame protection enabled). There are two code
paths that can occur when this disassociate frame is received:
1. Send out SA Query and receive a response from the AP within a
timeout. This means that the disassociate frame was not sent
from the AP and can be ignored.
2. Send out SA Query and receive no response. In this case it is
assumed that the AP went down ungracefully and is now back up.
Since frame protection is enabled, you must re-associate with
the AP.
Denis Kenzior