I have hit an issue with iwd 1.3 on Arch Linux (also reported in arch bug tracker https://bugs.archlinux.org/task/64855) where with a minimal iwd configuration using the built-in network configuration and systemd-resolved for DNS, iwd 1.3 does not properly add the DNS servers to systemd-resolved.
I saw this first on my laptop, which I temporarily worked around by simply disabling the internal network configuration and manually running dhclient. But, once I updated Arch on my workstation, and hit the same issue, I thought I should report it. I opened the bug in Arch's bug system, not knowing (and still not entirely sure) if the issue is specific to Arch Linux or not.
I found that by reverting the commit 930528e35, and removing one call to the added function that had been added after this patch was applied, the problem went away.
I am not sure if this is some bad interaction between iwd and systemd-resolved in Arch, or some wider issue. I have hit this issue on my home network using WPA2-PSK, as well as my work network (WPA2 Enterprise), so I do not think this is related to the network type of the connection. My iwd/main.conf file looks like this:
I use a config with EAP-Method=PEAP and
EAP-PEAP-Phase2-Method=MSCHAPV2, which results in (random?) core-dump.
This happens after authentication timeout or tls_reset_handshake. 
My system is an uptodate arch linux machine with iwd 1.2-1, Linux
5.4.2-arch1-1, glibc 2.30-3. If you need more information I am happy to
provide it. There is no problem with PreSharedKey Wifis.
Thank you for your time and this great tool.
Currently iwctl writes its history to a file named .iwctl_history in the users home directory. The XDG Base Directory Specification tries to standardize these kind of things (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html for details). The bottom line would probably be to:
* check XDG_DATA_HOME (with fall back to .local/share/) and save the history in an iwd subfolder of that directory
* potentially read (and migrate?) .iwctl_history from the home directory for compatibility purposes
Thanks for iwd by the way. Its a huge improvement over the wpa_supplicant world!
The first if case should be -10950, not 10950. Without the negative
this first case would get hit every time since signal strength values
are always negative.
src/rrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/rrm.c b/src/rrm.c
index a8b265d6..a117dce3 100644
@@ -243,7 +243,7 @@ static void rrm_build_measurement_report(struct rrm_request_info *info,
/* 802.11 Table 9-154 */
static uint8_t mdb_to_rcpi(int32_t mdb)
- if (mdb <= 10950)
+ if (mdb <= -10950)
else if (mdb >= -10950 && mdb < 0)
return (2 * (mdb + 11000)) / 100;
There are some server implementations that send requests that are
not "Password" but still want us send password. This commit modify
the behavior to send a warning and still try to auth with password.
This makes me able to auth with server in my school which sends
"Enter Aruba Login".
wpa_supplicant does not check if it is "Password".
src/eap-gtc.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/eap-gtc.c b/src/eap-gtc.c
index 9302257e..7788d44c 100644
@@ -56,11 +56,9 @@ static void eap_gtc_handle_request(struct eap_state *eap,
size_t secret_len = strlen(gtc->password);
uint8_t response[5 + secret_len];
- if (len < 8)
- goto error;
- if (strncmp((const char *)pkt, "Password", 8))
- goto error;
+ if (len < 8 || strncmp((const char *)pkt, "Password", 8))
+ l_warn("GTC request not understood, proceeding anyway: %.*s",
+ (int) len, (const char *) pkt);
memcpy(response + 5, gtc->password, secret_len);
@@ -69,10 +67,6 @@ static void eap_gtc_handle_request(struct eap_state *eap,
- l_error("invalid GTC request");
static int eap_gtc_check_settings(struct l_settings *settings,