When a wifi interface is added/removed to/from a bridge, a
RTM_NEW/DELLINK event is issued. This is the same event used to signal
when an interface is created/deleted.
For this reason the event generated by the bridge code has to be
properly distinguished and handled accordingly. Failing to do so will
result in inconsistencies in iwd which will think an interface has been
deleted when it was actually not.
Detect incoming NEW/DELLINK bridge events and reacts accordingly. For
now, this simply means printing a simple message, as there is no
special logic in iwd for this yet.
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.
