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.
In mac80211_hwsim each radio is assigned two addresses, the second (addr
1) being used over nl80211. In SendFrame we'd hardcode the mapping of
address 0 to address 1 even though we track all the addresses in radio_info,
so instead use that data to find the radio that has given address 0. Also
if no address 0 matches what was supplied over DBus try to find a matching
address 1.
There are ways userspace can request different addresses when managing
mac80211_hwsim radios and the hardcoded mapping would become wrong.
1) Renamed the test to reflect the usage of PEAP
2) Prevented the creation of an extra instance of iwd
3) Refactored to start catching the exceptions and properly
dispose an instance of iwd
4) Switched to list_devices with wait option
1) Removed duplicated entries form .conf
2) Refactored to start catching the exceptions and properly
dispose an instance of iwd
3) Switched to list_devices with wait option
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)
to fix compilation against MUSL libc.
The struct ethhdr does exists in netinet/if_ether.h and linux/if_ether.h
so including the linux headers after the libc headers lets libc_compat.h
work as intended.
Tim Kourt