The IWD thread

jasonwryan · 2018-06-16 09:04:28

amish wrote:

Nope - it seems that you are probably not using iwd. Hence do not know what has happened.
https://git.archlinux.org/svntogit/comm … ckages/iwd

Yes, because--as per Arch packaging policy--it is following upstream. Look at their git log.

amish · 2018-06-16 09:11:04

No he did not follow upstream... thats why I am complaining.

He removed upstream service file first (which was not required) .. introduced his own method of forcing user to use interface files instead.

Now he brings back upstream file (which is still not fixed correctly) - but thats ok.

But there was no need to remove interface service file which he introduced earlier.

So he broke things twice which could have been avoided by keeping both service files. (see my earlier post where I had asked why iwd.service file was removed)

Last edited by amish (2018-06-16 09:12:48)

illis · 2018-07-11 15:06:14

Has anyone got connman working with iwd (without wpa_supplicant installed)? I've tried launching connmand on the command line with

connmand --wifi=iwd_agent -n

but can't get scanning to work (No Carrier Error).

After spamming a few disable/enable/scan wifi commands I do get this in the journal.

dbus-daemon[488]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.941" (uid=0 pid=7349 comm="connmand --debug=VERBOSE --wifi=iwd_agent -n ") interface="fi.w1.wpa_supplicant1" member="CreateInterface" error name="(unset)" requested_reply="0" destination="fi.w1.wpa_supplicant1" (uid=0 pid=5268 comm="/usr/bin/wpa_supplicant -u ")

Seems like its still trying to use wpa_supplicant? I've installed connman via normal community package, which according to the PKGBUILD is supposed to have iwd enabled.

Can't seem to work this one out, any help would be much appreciated!

illis · 2018-07-12 06:29:31

Nevermind, managed to get it going. Had a couple of things I needed to do:
- Ignore the `scan wifi`
- Install the iwd-git from the aur, as the 0.3-1 version was giving me grief trying to connect to my 2.4GHz network - 5GHz worked fine.

duffydack · 2018-07-28 09:43:04

iwd from repo worked until I rebooted and ended up with a different interface name (the old wlan0). iwd-git fixed that. will test few days and then switch if no issues.

amish · 2018-07-28 11:10:40

iwd should not (not supposed to) change interface names. It must be something else.

duffydack · 2018-07-28 14:04:51

amish wrote:

iwd should not (not supposed to) change interface names. It must be something else.

Yeah, someone earlier mentioned same thing, possibly running before udev renames the if. Well something got fixed within the last 3 days since the last release was 3 days ago. I'll stick to -git until repo gets release update.

EDIT: ah crap, it's still failing to rename from wlan0 (systemd-udev saying device or resource busy). Rare but happens.

Last edited by duffydack (2018-08-11 18:56:23)

Sullome · 2018-08-12 19:08:25

I'm having some strange issues with IWD and PEAP-MSCHAPV2.

Previously I used ConnMan + WPA Supplicant. My connection was configured as a separate config file:

% cat /var/lib/connman/<SSID>.config
[service_<SSID>]
Type=wifi
Name=<SSID>
EAP=peap
Phase2=MSCHAPV2
Identity=<LOGIN>
Passphrase=<PASSWORD>
%

And this worked quite well.

I decided to check how IWD works. So I disabled ConnMan and WPA Supplicant (uninstalled it). And also modified .service file for iwd:

% cat /etc/systemd/system/iwd.service 
[Unit]
Description=Wireless service
Before=network.target
Wants=network.target

[Service]
ExecStart=/usr/lib/iwd/iwd
LimitNPROC=1

[Install]
Alias=multi-user.target.wants/iwd.service
%

And configured my connection this way (took this as an example):

% cat /var/lib/iwd/<SSID>.8021x
[Security]
EAP-Method=PEAP
EAP-Identity=anonymous
EAP-PEAP-Phase2-Method=MSCHAPV2
EAP-PEAP-Phase2-Identity=<LOGIN>
EAP-PEAP-Phase2-Password=<PASSWORD>

[Settings]
Autoconnect=True
%

Well, it failed. Here's the log lines about the connection:

авг 11 19:24:47 chromebook iwd[249]: PEAP TLS tunnel has disconnected with alert: 80
авг 11 19:24:48 chromebook iwd[249]: EAP completed with eapFail
авг 11 19:24:48 chromebook iwd[249]: 4-Way handshake failed for ifindex: 2, reason: 23

If I leave EAP-Identity empty, same thing happens, but without the first line about alert 80. And I think that it's because when it is empty, it fails to initiate PEAP, but with something in this field it does it, but fails to authorize with MSCHAPV2. Not sure about it.
Reason code 23, as far as I managed to find with google, says that there are some authorization errors.

I've already tried to remove Phase2 Identity and Password from the file and connect manually with iwctl — no success, same errors.

Can someone help me with this case?

Slithery · 2018-08-12 19:53:01

Which version of iwd are you using?

0.5 was very quickly superseded by 0.6 to fix some critical bugs.

Sullome · 2018-08-12 21:40:48

Slithery wrote:

Which version of iwd are you using?
0.5 was very quickly superseded by 0.6 to fix some critical bugs.

0.4
I think I'll wait for 0.6 and try again, then.

martyg · 2018-08-28 16:49:46

Hello. I am confused regarding interactions between iwd with the systemd networking deamon systemd-networkd.

I use systemd-networkd (Instead of NetworkManager or connman) on my laptop.
Everything seems to be fine just replacing wpa_supplicant with iwd.

However, I see this systemd bug https://github.com/systemd/systemd/issues/8157
And since it has been screened by Poettering, it is clear there is work here to be done.

Could someone explain what is missing right now in this configuration?

progandy · 2018-08-28 16:55:12

I think what is missing are automatic configuration changes like DNS server, static IP or routes depending on the SSID of the wifi network.
I'm not sure what the dbus api of iwd has to with that, though. I think it should be possible to use netlink events to monitor changes in the connection status.

Last edited by progandy (2018-08-28 17:00:14)

amish · 2018-08-29 01:50:44

Exactly iwd is working perfectly fine with systemd-networkd.

What is missing is what is mentioned by @progandy above
https://github.com/systemd/systemd/issues/9466

May be systemd-networkd can watch Dbus for SSID announcement etc.

tzxphntm36 · 2018-09-06 03:33:32

Is there a way to force or set TLS negotiation version? I work with a network (EAP-TLS method) that only uses TLS1.0. I have no control or sway to get that changed anytime soon, but have iwd working in every other way/network that I need would be nice to have this one working as well. Thanks

brebs · 2018-09-06 08:16:08

I tried iwd briefly. One reboot had the problem (which does not happen, when using wpa_supplicant):

# journalctl | grep -i "interface.*wlan0"
Sep 05 09:29:41 brebsc systemd-udevd[457]: Error changing net interface name 'wlan0' to 'wlp1s0': Device or resource busy
Sep 05 09:29:41 brebsc systemd-udevd[457]: could not rename interface '2' from 'wlan0' to 'wlp1s0': Device or resource busy

As speculation, presumably there is a race condition, due to dependencies:

# cd /usr/lib/systemd/system
# colordiff -u wpa_supplicant@.service iwd.service 
--- wpa_supplicant@.service	2018-08-10 15:19:09.000000000 +0100
+++ iwd.service	2018-08-27 01:14:02.000000000 +0100
@@ -1,15 +1,13 @@
 [Unit]
-Description=WPA supplicant daemon (interface-specific version)
-Requires=sys-subsystem-net-devices-%i.device
-After=sys-subsystem-net-devices-%i.device
+Description=Wireless service
 Before=network.target
 Wants=network.target
 
-# NetworkManager users will probably want the dbus version instead.
-
 [Service]
-Type=simple
-ExecStart=/usr/bin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I
+Type=dbus
+BusName=net.connman.iwd
+ExecStart=/usr/lib/iwd/iwd
+LimitNPROC=1
 
 [Install]
-Alias=multi-user.target.wants/wpa_supplicant@%i.service
+WantedBy=multi-user.target

pancho · 2018-09-16 07:13:39

Hi, folks!

I deployed iwd on two boxen, one is an Intel NUC, with an Intel wifi device; there iwd starts flawlessly, recognizing the device without any hassle.
The other one is a Dell XPS 13, with a Qualcomm Atheros QCA6174. In this device, iwd starts, but, as on similar reports in this thread, no wifi device is detected, and has to be restarted manually in order to do so.

After seeing previous post by @brebs, where a diff between iwd's and wpa_supplicant's unit file is shown, and a race condition is suggested, I went on and created an override file for iwd, adding the missing Requires= and After= stanzas. Now it works like a charm!

A very similar fix is described here: https://renediepstraten.nl/?p=62, which uses BindsTo= instead of Requires=. See man systemd.unit for an explanation of the difference.

At any rate, this fix is not completely satisfactory IMHO, since we have to know beforehand the name of the wifi device in order for it to work. In the wpa_supplicant case, that was ok, because the service would be instantiated with the name of the device as a parameter. iwd, OTOH, will try to detect all wifi devices in the system, but should do so only after those are already initialized.

I'm currently looking for ways to use wildcards in the Requires= / After= stanzas, but the systemd docs don't mention them.

Thoughts?

Last edited by pancho (2018-09-16 07:15:14)

progandy · 2018-09-16 09:19:40

iwd has a --nointerfaces switch which you could use to blacklist the kernel interface names similar to the denyinterfaces configuration in dhcpcd.

Exec=iwd ... --nointerfaces "wlan[0-9]*"

Last edited by progandy (2018-09-16 09:27:21)

E5ten · 2018-09-18 18:12:44

I don't have that option.
EDIT: Yes I do, I entered the command multiple times so I must've just made like 5+ typos apparently.

Last edited by E5ten (2018-09-18 18:17:57)

scruffidog · 2018-09-25 22:26:41

Anyone else who upgraded to 0.8 and also running connman is getting a connman_iwd.service crash ?

Sep 25 18:15:29 hydra kernel: audit: type=1300 audit(1537913729.597:169): arch=c000003e syscall=54 success=yes exit=0 a0=9 a1=0 a2=40 a3=564048a86d10 items=0 ppid=1 pid=9458 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4
294967295 comm="connmand" exe="/usr/bin/connmand" key=(null)
Sep 25 18:15:29 hydra connmand[9458]: Checking loopback interface settings
Sep 25 18:15:29 hydra connmand[9458]: System hostname is hydra
Sep 25 18:15:29 hydra connmand[9458]: __connman_inet_get_pnp_nameservers: Cannot read /proc/net/pnp Failed to open file “/proc/net/pnp”: No such file or directory
Sep 25 18:15:29 hydra connmand[9458]: Cannot create /var/run/connman/resolv.conf falling back to /etc/resolv.conf
Sep 25 18:15:29 hydra connmand[9458]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
Sep 25 18:15:29 hydra connmand[9458]: lo {newlink} index 1 operstate 0 <UNKNOWN>
Sep 25 18:15:29 hydra dbus-daemon[383]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.2626' (uid=0 pid=9458 comm="/usr/bin/connmand --wifi=iwd_agent -n ")
Sep 25 18:15:29 hydra connmand[9458]: enp3s0 {create} index 2 type 1 <ETHER>
Sep 25 18:15:29 hydra connmand[9458]: enp3s0 {update} flags 36867 <UP>
Sep 25 18:15:29 hydra connmand[9458]: enp3s0 {newlink} index 2 address F0:76:1C:63:AB:D3 mtu 1500
Sep 25 18:15:29 hydra connmand[9458]: enp3s0 {newlink} index 2 operstate 2 <DOWN>
Sep 25 18:15:29 hydra connmand[9458]: Adding interface enp3s0 [ ethernet ]
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {create} index 3 type 1 <ETHER>
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {RX} 741074 packets 983205233 bytes
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {TX} 404940 packets 51663314 bytes
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {update} flags 69699 <UP,RUNNING,LOWER_UP>
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {newlink} index 3 address D0:7E:35:9B:90:56 mtu 1500
Sep 25 18:15:29 hydra connmand[9458]: wlp4s0 {newlink} index 3 operstate 6 <UP>
Sep 25 18:15:29 hydra connmand[9458]: Adding interface wlp4s0 [ wifi ]
Sep 25 18:15:29 hydra connmand[9458]: Aborting (signal 11) [/usr/bin/connmand]
Sep 25 18:15:29 hydra connmand[9458]: ++++++++ backtrace ++++++++
Sep 25 18:15:29 hydra connmand[9458]: #0  0x7f7f6130ce00 in /usr/lib/libc.so.6
Sep 25 18:15:29 hydra connmand[9458]: #1  0x564047565ea7 in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #2  0x56404756646b in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #3  0x5640475d00d4 in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #4  0x5640475d1547 in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #5  0x7f7f6165301e in /usr/lib/libdbus-1.so.3
Sep 25 18:15:29 hydra connmand[9458]: #6  0x7f7f61656b5c in /usr/lib/libdbus-1.so.3
Sep 25 18:15:29 hydra connmand[9458]: #7  0x5640475caed1 in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #8  0x7f7f616fe271 in /usr/lib/libglib-2.0.so.0
Sep 25 18:15:29 hydra connmand[9458]: #9  0x7f7f616fff89 in /usr/lib/libglib-2.0.so.0
Sep 25 18:15:29 hydra connmand[9458]: #10 0x7f7f61700f62 in /usr/lib/libglib-2.0.so.0
Sep 25 18:15:29 hydra connmand[9458]: #11 0x564047545c8b in /usr/bin/connmand
Sep 25 18:15:29 hydra connmand[9458]: #12 0x7f7f612f9223 in /usr/lib/libc.so.6
Sep 25 18:15:29 hydra connmand[9458]: +++++++++++++++++++++++++++

After downgrading back to 0.7, everything is working fine again. Clues to troubleshoot ?

Last edited by scruffidog (2018-09-30 02:23:06)

jasonwryan · 2018-09-25 23:58:55

Please use code tags: https://wiki.archlinux.org/index.php/Co … s_and_code

shorty · 2018-09-27 20:21:43

Having one minor issue. When I power off my wireless device using rfkill and then I go to turn it back on later, I have to restart iwd.service every time or else iwd won't auto connect. Other than that, have been using iwd along with systemd-networkd and it has been working like a charm.

AGT · 2018-10-14 16:14:16

scruffidog, yes, I get that error snippet too:

root@Portable:/root> pacman -Q iwd
iwd 0.8-1
root@Portable:/root> /usr/bin/connmand --wifi=iwd_agent -n
connmand[5180]: Connection Manager version 1.36
connmand[5180]: Checking loopback interface settings
connmand[5180]: System hostname is Portable
connmand[5180]: __connman_inet_get_pnp_nameservers: Cannot read /proc/net/pnp Failed to open file “/proc/net/pnp”: No such file or directory
connmand[5180]: Cannot create /var/run/connman/resolv.conf falling back to /etc/resolv.conf
connmand[5180]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
connmand[5180]: lo {newlink} index 1 operstate 0 <UNKNOWN>
connmand[5180]: enp2s0 {create} index 2 type 1 <ETHER>
connmand[5180]: enp2s0 {update} flags 4099 <UP>
connmand[5180]: enp2s0 {newlink} index 2 address B8:70:F4:7E:34:63 mtu 1500
connmand[5180]: enp2s0 {newlink} index 2 operstate 2 <DOWN>
connmand[5180]: Adding interface enp2s0 [ ethernet ]
connmand[5180]: wlp3s0 {create} index 3 type 1 <ETHER>
connmand[5180]: wlp3s0 {RX} 1977 packets 1093441 bytes
connmand[5180]: wlp3s0 {TX} 1792 packets 253401 bytes
connmand[5180]: wlp3s0 {update} flags 36867 <UP>
connmand[5180]: wlp3s0 {newlink} index 3 address C0:F8:DA:4C:C7:7F mtu 1500
connmand[5180]: wlp3s0 {newlink} index 3 operstate 2 <DOWN>
connmand[5180]: Adding interface wlp3s0 [ wifi ]
connmand[5180]: Aborting (signal 11) [/usr/bin/connmand]
connmand[5180]: ++++++++ backtrace ++++++++
connmand[5180]: #0  0x7efe473f3e00 in /usr/lib/libc.so.6
connmand[5180]: #1  0x5582dbd4eea7 in /usr/bin/connmand
connmand[5180]: #2  0x5582dbd4f46b in /usr/bin/connmand
connmand[5180]: #3  0x5582dbdb90d4 in /usr/bin/connmand
connmand[5180]: #4  0x5582dbdba547 in /usr/bin/connmand
connmand[5180]: #5  0x7efe4773a01e in /usr/lib/libdbus-1.so.3
connmand[5180]: #6  0x7efe4773db5c in /usr/lib/libdbus-1.so.3
connmand[5180]: #7  0x5582dbdb3ed1 in /usr/bin/connmand
connmand[5180]: #8  0x7efe477e5271 in /usr/lib/libglib-2.0.so.0
connmand[5180]: #9  0x7efe477e6f89 in /usr/lib/libglib-2.0.so.0
connmand[5180]: #10 0x7efe477e7f62 in /usr/lib/libglib-2.0.so.0
connmand[5180]: #11 0x5582dbd2ec8b in /usr/bin/connmand
connmand[5180]: #12 0x7efe473e0223 in /usr/lib/libc.so.6
connmand[5180]: +++++++++++++++++++++++++++

scruffidog · 2018-10-17 02:49:35

Just tried the latest update iwd-0.9-1 and it seems to have the identical problem of crashing connman. There does seem to be additional wierdness in the interface naming under 0.9, the interfaces were named wlan0 and eth0, not the wlpXs# and enpXs#. I chalked it up to the new kernel rev, but then after I downgraded iwd back to 0.7, the naming convention reverted back...

So right now I got a hold on the iwd pkg until someone can point me in the right direction on troubleshooting this.

sjensen · 2018-10-19 16:58:48

I just gave iwd (0.9-1) a try and it seems to work very well and fast. Very nice work!

I would suggest, that it would be cool, if one could paste the psk into "iwctl" for a new connection. This seems not intended? Typing out long keys is a burden and prone to failure. I know there are other fancy ways to get the key, but i like it, when I can also use a cli. :-)

Is the integration into NetworkManager already complete enough to drop wpa_supplicant? Creating and using a connection via NetworkManager seems to work fine, but will start both wpa_supplicant and iwd units. When I manually stop wpa_supplicant or even mask it, nothing works. *Should* it work or is it simply not yet ready?

damjan · 2018-10-22 14:04:58

@sjensen
wpa_supplicant and iwd, can't work at the same time. Typically, both are started on demand (dbus activation), so if you configure NM to use iwd, then only iwd will start.

Arch Linux

#51 2018-06-16 09:04:28

Re: The IWD thread

#52 2018-06-16 09:11:04

Re: The IWD thread

#53 2018-07-11 15:06:14

Re: The IWD thread

#54 2018-07-12 06:29:31

Re: The IWD thread

#55 2018-07-28 09:43:04

Re: The IWD thread

#56 2018-07-28 11:10:40

Re: The IWD thread

#57 2018-07-28 14:04:51

Re: The IWD thread

#58 2018-08-12 19:08:25

Re: The IWD thread

#59 2018-08-12 19:53:01

Re: The IWD thread

#60 2018-08-12 21:40:48

Re: The IWD thread

#61 2018-08-28 16:49:46

Re: The IWD thread

#62 2018-08-28 16:55:12

Re: The IWD thread

#63 2018-08-29 01:50:44

Re: The IWD thread

#64 2018-09-06 03:33:32

Re: The IWD thread

#65 2018-09-06 08:16:08

Re: The IWD thread

#66 2018-09-16 07:13:39

Re: The IWD thread

#67 2018-09-16 09:19:40

Re: The IWD thread

#68 2018-09-18 18:12:44

Re: The IWD thread

#69 2018-09-25 22:26:41

Re: The IWD thread

#70 2018-09-25 23:58:55

Re: The IWD thread

#71 2018-09-27 20:21:43

Re: The IWD thread

#72 2018-10-14 16:14:16

Re: The IWD thread

#73 2018-10-17 02:49:35

Re: The IWD thread

#74 2018-10-19 16:58:48

Re: The IWD thread

#75 2018-10-22 14:04:58

Re: The IWD thread

Board footer