You are not logged in.
tried iwd-0.10-1 with connman and still no joy. Still complians about dbus
How many people are using connman as the networking mgmnt facility ?
Offline
tried iwd-0.10-1 with connman and still no joy. Still complians about dbus
How many people are using connman as the networking mgmnt facility ?
Same failure for me, I've stuck with 0.7-1
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Is it possible to decrypt the password for an already known network?
Offline
@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.
Well no, and that is exactly the problem. "iwd" and "wpa_supplicant" are started both at the same time over dbus, if i use
[device]
wifi.backend=iwd
I had to manually remove/mask "dbus-fi.w1.wpa_supplicant1.service".
Offline
was wpa_supplicant explicitly enabled? 'cause it doesn't start for me here when NM is set to use iwd
Offline
Is NM supposed to pass all the relevant info such as passwords etc to iwd the same way it does with wpa_supplicant?
I tried stopping NM, changing the backend to iwd - made sure wpa_s was not running - restarted NM and waited - no connection happened. logs had iwd complaing:
iwd[3906]: Unable to open /var/lib/iwd: No such file or directory
i have NOT set up any network by hand using iwctl - as I assumed changing backends that NM would pass all the relevant info to iwd.
changing backend back to wpa_supplicant works again.
So does anyone know whether NM able to use iwd without any additional intervention so that existing passwords, routes, ipv4/ipv6 and special dns settings will continue to work the same way?
thanks
Offline
I had similar issues with enabling iwd NetworkManager. I have abandoned using NetworkManager alltogether though. Now I use iwd with dhcpcd.
I have a weirder issue. I use udev to rename my wireless interface to 'wifi'. Lately, I noticed very often that udev cannot rename the device because device is busy. Initially I thought the problem was with dhcpcd, and made the interfaces managed explicit and that seemingly solved the issue. However, a while later I was having the issue again.
Now I realize that iwd captures the interface before udev can change the name on boot sometimes, and prevents it from being renamed; which screws up some other stuff down the line. I followed the guide on another thread and issued the following override;
$ cat /etc/systemd/system/iwd.service.d/override.conf
[Unit]
Before=network.target
Wants=network.target
[Service]
ExecStart=
ExecStart=/usr/lib/iwd/iwd --nointerfaces "wlan[0-9]*"
This is fine, the interface is renamed. But if iwd is started before udev can rename, it cannot then recognize the newly made available `wifi` interface.
Last edited by bbaserdem (2018-11-23 03:36:55)
Offline
$ cat /etc/systemd/system/iwd.service.d/override.conf [Unit] Before=network.target Wants=network.target [Service] ExecStart= ExecStart=/usr/lib/iwd/iwd --nointerfaces "wlan[0-9]*"
This is fine, the interface is renamed. But if iwd is started before udev can rename, it cannot then recognize the newly made available `wifi` interface.
My setup suffers the same udev renaming race, tho it's very hit and miss. I tried this override which gives me the proper iface name every boot, but never actually gets an ip, until I restart iwd and networkd. Gone back to wpa_supplicant, for now....
Offline
I've run into the same race condition between udev and iwd that's referenced by systemd#7293. I actually opened a thread also.
I've sinced moved to the following override which has been working well:
$ cat /etc/systemd/system/iwd.service.d/override.conf
[Unit]
BindsTo=sys-subsystem-net-devices-wifi0.device
After=sys-subsystem-net-devices-wifi0.device
[Service]
ExecStart=
ExecStart=/usr/lib/iwd/iwd --interface wifi0
Interested in other's thoughts.
--edit
Should give credit to Pancho's post from this same thread which also has relevant links.
Last edited by CarbonChauvinist (2018-11-25 15:05:30)
"the wind-blown way, wanna win? don't play"
Offline
I've run into the same race condition between udev and iwd that's referenced by systemd#7293. I actually opened a thread also.
I've sinced moved to the following override which has been working well:
$ cat /etc/systemd/system/iwd.service.d/override.conf [Unit] BindsTo=sys-subsystem-net-devices-wifi0.device After=sys-subsystem-net-devices-wifi0.device [Service] ExecStart= ExecStart=/usr/lib/iwd/iwd --interface wifi0
Interested in other's thoughts.
Looking good so far. Nice.
Offline
Still no way to get connman working with iwd? wpa_supplicant is a disaster for me - iwd fixes so many problems.
Offline
Still no way to get connman working with iwd? wpa_supplicant is a disaster for me - iwd fixes so many problems.
Using iwd 0.7 with connman. Thats been working fine. I did try 10.? at some point, but ran into issues with something renaming the network interface - so I reverted back - I think there other people with the same issue further up this thread. Haven't tried any newer versions since.
Offline
gothmog123 wrote:Still no way to get connman working with iwd? wpa_supplicant is a disaster for me - iwd fixes so many problems.
Using iwd 0.7 with connman. Thats been working fine.
No scanning though?
Offline
illis wrote:gothmog123 wrote:Still no way to get connman working with iwd? wpa_supplicant is a disaster for me - iwd fixes so many problems.
Using iwd 0.7 with connman. Thats been working fine.
No scanning though?
Scanning works, but I think the trick is to use iwctl to scan
$ iwctl
[iwd]# device wlan0 scan
[iwd]# device wlan0 get-networks
$ connmanctl
connmanctl> services
Offline
jasonwryan wrote:illis wrote:Using iwd 0.7 with connman. Thats been working fine.
No scanning though?
Scanning works, but I think the trick is to use iwctl to scan
$ iwctl [iwd]# device wlan0 scan [iwd]# device wlan0 get-networks
$ connmanctl connmanctl> services
Cool: thanks for the tip!
Offline
Got iwd working fine now, except for 1 issue. NFS mounts fail to unmount during reboot/shutdown, and waits the usual 90s before it gives up. I could lower the timer, but I'd rather fix the issue with IWD. No issue with wpa_supplicant. Anyone else same?
Offline
How are you mounting your NFS shares to begin with?
The following may help from the NFS wiki - look into using the systemd automount if you're not already.
If shutdown/reboot holds too long because of NFS, enable NetworkManager-wait-online.service to ensure that NetworkManager is not exited before the NFS volumes are unmounted. You may also try to add the x-systemd.requires=network-online.target mount option if shutdown takes too long.
Last edited by CarbonChauvinist (2018-12-04 20:44:16)
"the wind-blown way, wanna win? don't play"
Offline
How are you mounting your NFS shares to begin with?
The following may help from the NFS wiki - look into using the systemd automount if you're not already.
If shutdown/reboot holds too long because of NFS, enable NetworkManager-wait-online.service to ensure that NetworkManager is not exited before the NFS volumes are unmounted. You may also try to add the x-systemd.requires=network-online.target mount option if shutdown takes too long.
already using automount, with networkd (systemd-networkd-wait-online.service is enabled automatically when I enable networkd)
host:/share /mnt/share nfs noauto,x-systemd.automount 0 0
I'll give x-systemd.requires=network-online.target a shot, thanks
Offline
If shutdown/reboot holds too long because of NFS, enable NetworkManager-wait-online.service to ensure that NetworkManager is not exited before the NFS volumes are unmounted. You may also try to add the x-systemd.requires=network-online.target mount option if shutdown takes too long.
Tried it but still the same, waiting 90s. I'll stick an idle timeout in the fstab mount for now. It'll do.
Offline
Just a FYI if you get 44 minutes to spare.
Marcel Holtmann gave an overview/history/status/todo talk at the Embedded Linux Conference - Europe for iwd recently (October 2018).
https://www.youtube.com/watch?v=QIqT2obSPDk
He covers the recent status for ConnMan, NetworkManager, ChromeOS, and iwdctl support about 20 minutes in.
The general take away I get is that iwd is still a WiP (Work in Progress), but it seems to be moving along nicely.
Now, if I could just shake this feeling that somehow Lennart Poettering is involved.
Offline
I'm testing iwd + dhcpcd:
Do I have to enable both systemd units ?
Or is there another way, like this hook for wpa_supplicant https://wiki.archlinux.org/index.php/Dh … supplicant ?
Offline
I'm testing iwd + dhcpcd:
Do I have to enable both systemd units ?Or is there another way, like this hook for wpa_supplicant https://wiki.archlinux.org/index.php/Dh … supplicant ?
Yeah just enable both and it works like magic. But you won't have a tray applet.
Offline
I tested a while: for me dhcpcd + iwd only works on every 2nd boot.
To get wireless working I figured out, that I have to restart iwd manually.
Setup:
dhcpcd enabled for all interfaces
iwd enabled
masked: systemd-networkd systemd-resolved
case 1: everything is fine after boot:
-- Reboot --
Dec 15 10:08:11 l18 systemd[1]: Starting Wireless service...
Dec 15 10:08:12 l18 iwd[303]: No asymmetric key support found.
Dec 15 10:08:12 l18 iwd[303]: TLS based WPA-Enterprise authentication methods will not function.
Dec 15 10:08:12 l18 iwd[303]: Kernel 4.20+ is required for this feature.
Dec 15 10:08:12 l18 iwd[303]: The following options are missing in the kernel:
Dec 15 10:08:12 l18 iwd[303]: CONFIG_ASYMMETRIC_KEY_TYPE
Dec 15 10:08:12 l18 iwd[303]: CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
Dec 15 10:08:12 l18 iwd[303]: CONFIG_PKCS7_MESSAGE_PARSER
Dec 15 10:08:12 l18 iwd[303]: CONFIG_X509_CERTIFICATE_PARSER
Dec 15 10:08:12 l18 iwd[303]: CONFIG_PKCS8_PRIVATE_KEY_PARSER
Dec 15 10:08:12 l18 iwd[303]: Wireless daemon version 0.12
Dec 15 10:08:12 l18 iwd[303]: Skipping optional configuration file /etc/iwd/main.conf
Dec 15 10:08:12 l18 systemd[1]: Started Wireless service.
Dec 15 10:08:12 l18 iwd[303]: Wiphy: 0, Name: phy0
Dec 15 10:08:12 l18 iwd[303]: Bands: 2.4 GHz 5 GHz
Dec 15 10:08:12 l18 iwd[303]: Ciphers: CCMP TKIP
Dec 15 10:08:12 l18 iwd[303]: Supported iftypes: ad-hoc station
Dec 15 10:08:12 l18 iwd[303]: No ControlPortOverNL80211 setting, defaulting to True
Dec 15 10:08:12 l18 iwd[303]: Unable to add the net.connman.iwd.Adapter interface to /0
Dec 15 10:08:12 l18 iwd[303]: Unable to add the org.freedesktop.DBus.Properties interface to /0
Dec 15 10:08:12 l18 iwd[303]: Wiphy: 0, Name: phy0
Dec 15 10:08:12 l18 iwd[303]: Bands: 2.4 GHz 5 GHz
Dec 15 10:08:12 l18 iwd[303]: Ciphers: CCMP TKIP
Dec 15 10:08:12 l18 iwd[303]: Supported iftypes: ad-hoc station
Dec 15 10:08:17 l18 iwd[303]: hardware_rekey not supported
case 2: On this boot, I had to restart iwd (Line: Terminate !) to get wireless working:
-- Reboot --
Dec 15 10:32:36 l18 systemd[1]: Starting Wireless service...
Dec 15 10:32:37 l18 iwd[309]: No asymmetric key support found.
Dec 15 10:32:37 l18 iwd[309]: TLS based WPA-Enterprise authentication methods will not function.
Dec 15 10:32:37 l18 iwd[309]: Kernel 4.20+ is required for this feature.
Dec 15 10:32:37 l18 iwd[309]: The following options are missing in the kernel:
Dec 15 10:32:37 l18 iwd[309]: CONFIG_ASYMMETRIC_KEY_TYPE
Dec 15 10:32:37 l18 iwd[309]: CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
Dec 15 10:32:37 l18 iwd[309]: CONFIG_PKCS7_MESSAGE_PARSER
Dec 15 10:32:37 l18 iwd[309]: CONFIG_X509_CERTIFICATE_PARSER
Dec 15 10:32:37 l18 iwd[309]: CONFIG_PKCS8_PRIVATE_KEY_PARSER
Dec 15 10:32:37 l18 iwd[309]: Wireless daemon version 0.12
Dec 15 10:32:37 l18 iwd[309]: Skipping optional configuration file /etc/iwd/main.conf
Dec 15 10:32:37 l18 systemd[1]: Started Wireless service.
Dec 15 10:32:37 l18 iwd[309]: Wiphy: 0, Name: phy0
Dec 15 10:32:37 l18 iwd[309]: Bands: 2.4 GHz 5 GHz
Dec 15 10:32:37 l18 iwd[309]: Ciphers: CCMP TKIP
Dec 15 10:32:37 l18 iwd[309]: Supported iftypes: ad-hoc station
Dec 15 10:32:37 l18 iwd[309]: No ControlPortOverNL80211 setting, defaulting to True
Dec 15 10:33:11 l18 iwd[309]: 4-Way handshake failed for ifindex: 3, reason: 15
Dec 15 10:45:20 l18 iwd[309]: Terminate
Dec 15 10:45:20 l18 iwd[309]: Removing scan context for ifindex: 3
Dec 15 10:45:20 l18 systemd[1]: Stopping Wireless service...
Dec 15 10:45:21 l18 iwd[309]: D-Bus disconnected, quitting...
Dec 15 10:45:21 l18 systemd[1]: Stopped Wireless service.
Dec 15 10:45:21 l18 systemd[1]: Starting Wireless service...
Dec 15 10:45:21 l18 iwd[582]: No asymmetric key support found.
Dec 15 10:45:21 l18 iwd[582]: TLS based WPA-Enterprise authentication methods will not function.
Dec 15 10:45:21 l18 iwd[582]: Kernel 4.20+ is required for this feature.
Dec 15 10:45:21 l18 iwd[582]: The following options are missing in the kernel:
Dec 15 10:45:21 l18 iwd[582]: CONFIG_ASYMMETRIC_KEY_TYPE
Dec 15 10:45:21 l18 iwd[582]: CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
Dec 15 10:45:21 l18 iwd[582]: CONFIG_PKCS7_MESSAGE_PARSER
Dec 15 10:45:21 l18 iwd[582]: CONFIG_X509_CERTIFICATE_PARSER
Dec 15 10:45:21 l18 iwd[582]: CONFIG_PKCS8_PRIVATE_KEY_PARSER
Dec 15 10:45:21 l18 iwd[582]: Wireless daemon version 0.12
Dec 15 10:45:21 l18 iwd[582]: Skipping optional configuration file /etc/iwd/main.conf
Dec 15 10:45:21 l18 iwd[582]: Wiphy: 0, Name: phy0
Dec 15 10:45:21 l18 iwd[582]: Bands: 2.4 GHz 5 GHz
Dec 15 10:45:21 l18 iwd[582]: Ciphers: CCMP TKIP
Dec 15 10:45:21 l18 iwd[582]: Supported iftypes: ad-hoc station
Dec 15 10:45:21 l18 iwd[582]: No ControlPortOverNL80211 setting, defaulting to True
Dec 15 10:45:21 l18 systemd[1]: Started Wireless service.
Dec 15 10:45:25 l18 iwd[582]: hardware_rekey not supported
As far as I can see the difference is: to get wireless working the log has to show "hardware_rekey not supported".
Any ideas on this ?
Offline
I tested a while: for me dhcpcd + iwd only works on every 2nd boot.
To get wireless working I figured out, that I have to restart iwd manually.As far as I can see the difference is: to get wireless working the log has to show "hardware_rekey not supported".
Any ideas on this ?
Don't know how much this will help, but I have systemd device renaming disabled, so my wireless is always wlan0, maybe you can try that.
Offline
Has anybody found a way to connect to an access point by BSSID instead of SSID? No luck with using BSSID with `connect` or `connect-hidden`.
Offline