The IWD thread

progandy · 2018-12-19 19:01:01

n8henrie wrote:

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`.

There is no way, iwd doesn't expose BSSIDs, and BSS / AP information is squashed into networks. IWD is designed to be the automagic tool which handles all those pesky technical details for you after you select a network name and give your authentication info.

Last edited by progandy (2018-12-19 19:02:42)

ua4000 · 2018-12-20 08:31:59

Have you tried the
https://wiki.archlinux.org/index.php/Iw … figuration
and create the configuration file by hand in /var/lib/iwd ?

Also see here
https://git.kernel.org/pub/scm/network/ … enNetworks
for the extra option

ignore_broadcast_ssid=1

On the other hand, it's maybe not working yet:
https://wiki.debian.org/NetworkManager/iwd

Known issues
As of right now the only known issue with iwd is the inability to connect to hidden SSIDs. Feedback about your success or failure with iwd is warmly welcome!

n8henrie · 2018-12-20 16:50:24

progandy wrote:

IWD is designed to be the automagic tool which handles all those pesky technical details for you after you select a network name and give your authentication info.

Seems to be working great in general but my router conveniently(?) broadcasts my 2.4GHz and 5GHz networks under the same SSID (so some devices like my iPhone automatically use the 5 GHz when in range and switch to the 2.4GHz when farther away). But my new Arch box will only connect to the 2.4 with iwd, missing out on the 802.11ac speeds.

If I split it out into a separate network it connects to the 5GHz fine, so it seems to have the ability, but when under the SSID it will only use the 2.4.

With wpa_supplicant I can just specify the BSSID which works great, so I guess I'll go back to that for now.

ua4000 wrote:

Have you tried the
Also see here
https://git.kernel.org/pub/scm/network/ … enNetworks
for the extra option
ignore_broadcast_ssid=1

I don't see this config option anywhere in the actual source code, just in those tests.

$ git --no-pager grep -r -i ignore_broadcast_ssid
autotests/testHiddenNetworks/ssidHiddenOpen.conf:ignore_broadcast_ssid=1
autotests/testHiddenNetworks/ssidHiddenWPA.conf:ignore_broadcast_ssid=1
autotests/testHiddenNetworks/ssidOverlap1.conf:ignore_broadcast_ssid=1
autotests/testHiddenNetworks/ssidOverlap2.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1
autotests/testScan/ssid_hidden.conf:ignore_broadcast_ssid=1

Last edited by n8henrie (2018-12-20 16:50:46)

progandy · 2018-12-20 19:51:26

n8henrie wrote:

If I split it out into a separate network it connects to the 5GHz fine, so it seems to have the ability, but when under the SSID it will only use the 2.4.

network_bss_select might have to be updated with more intelligent logic that prefers 5GHz networks when the signal strength is good enough and only a bit less than the 2.4GHz signal.
https://git.kernel.org/pub/scm/network/ … ork.c#n652

n8henrie · 2018-12-20 23:14:59

Looks like it might already take it into account a bit with this ranking algorithm: https://git.kernel.org/pub/scm/network/ … can.c#n997

Last edited by n8henrie (2018-12-20 23:15:15)

ua4000 · 2018-12-21 17:29:04

gothmog123 wrote:

ua4000 wrote:
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.

Thanks for the help. I was thinking about it, also about adding a delay for starting iwd.service, e.g. 30s.

But for now, I had another idea, I enabled haveged to increase system entropy since I think you need some random numbers to use PSK...
6 of 6 reboots were successful afterwards.

Kampfpudding · 2019-01-07 20:59:33

Apparently, some user in this thread have no problems using connman with iwd. When iwd is running and I start connman, I get

Aborting (signal 11) [connmand]

and connman fails. The same happens when connman is started without iwd running (which works fine), but then after I start iwd (because I need a backend of course) connman crashes again. The same goes for starting connman with the

--wifi=iwd_agent

option.

I looked around a bit and found one entry here but the repo version of connman already is the latest (1.36-1). I tried iwd-git from the AUR, hoping there might be some fix that is not yet available for the repo version.

Any ideas? I would love to get rid of dhcpcd and just use connman instead. I know there are other DHCP clients out there, but this bugs me very much and would really like to have it fixed.

rsmarples · 2019-01-07 23:16:10

Kampfpudding wrote:

I would love to get rid of dhcpcd and just use connman instead. I know there are other DHCP clients out there, but this bugs me very much and would really like to have it fixed.

Why do you want to get rid of dhcpcd?
As the author I'd like to know how I can improve it.

Kampfpudding · 2019-01-08 23:16:11

Oh nothing serious. It's just one more thing I need to keep track of on top of iwd. So connman would kind of combine two packages into one. Additionally I feel like when I drop my connection, dhcpcd causes trouble of some kind (I usually have to restart it in order to get an connection/local IP. Might be on iwd's side, though). This sounds really vague and that's because it is. I haven't really looked into it

Last edited by Kampfpudding (2019-01-08 23:18:57)

Binabik · 2019-01-09 09:10:46

Like for others, it is crucial for me to control which BSS my device connects to.

n8henrie wrote:

Looks like it might already take it into account a bit with this ranking algorithm: https://git.kernel.org/pub/scm/network/ … can.c#n997

This ranking algorithm looks quite hard-coded. Does anyone know if there are plans to
a) either let the user control the BSS that will be chosen
b) or make the ranking algorithm configurable?

Until then, I would rather stick with wpa_supplicant although I like the concept of iwd because wpa_supplicant gives me more control about how I will connect.

Troels · 2019-01-12 21:26:54

Hello, I just want to say, if you've had any trouble connecting to eduroam though EAP+PEAP+MSCHAPv2 it should be solved now. The fix is in the git master. I went to IRC and provided debug logs, and the devs were super helpful.

andrewj · 2019-01-13 13:30:13

scruffidog wrote:

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 ?

I had the same issue, which is caused by a null pointer issue in connman's iwd plugin. It has already beeen reported upstream: https://01.org/jira/browse/CM-693

I confirmed this through debugging, and got it working by recompiling through ABS with the following amended prepare() function in the PKGBUILD:

prepare(){
  cd "${pkgname}-${pkgver}"
  patch -Np1 -i "${srcdir}/allow_group_network.diff"

  echo "Patching strcmp() to g_strcmp0() in iwd.c to avoid NULL issues..."
  sed -i -e 's/strcmp(/g_strcmp0(/g' plugins/iwd.c
}

chr0mag · 2019-01-24 03:45:29

Running IWD + systemd-networkd without a major issue. A few initial observations.

IWD seems less tolerant of the iwlwifi power saving settings I had enabled. Recent kernels started showing the following iwlwifi errors on boot.

Jan 23 15:27:53 thinkpad kernel: iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
Jan 23 15:27:53 thinkpad kernel: iwlwifi 0000:04:00.0: loaded firmware version 36.9f0a2d68.0 op_mode iwlmvm
Jan 23 15:27:53 thinkpad kernel: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
Jan 23 15:27:53 thinkpad kernel: iwlwifi 0000:04:00.0: base HW address: 34:f3:9a:bc:84:e1
Jan 23 15:27:53 thinkpad kernel: iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Error sending MAC_CONTEXT_CMD: time out after 2000ms.
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Current CMD queue read_ptr 34 write_ptr 35
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Status: 0x00000100, count: 6
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Loaded firmware version: 36.9f0a2d68.0
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN       
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x000002F0 | trm_hw_status0
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | trm_hw_status1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00024180 | branchlink2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x000397EA | interruptlink1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00036E94 | interruptlink2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | data1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000080 | data2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x07830000 | data3
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | beacon time
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00213B41 | tsf low
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | tsf hi
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | time gp1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00213B42 | time gp2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000001 | uCode revision type
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000024 | uCode version major
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x9F0A2D68 | uCode version minor
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000201 | hw version
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00880000 | board version
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x002001C8 | hcmd
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00022000 | isr0
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00800000 | isr1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x08001802 | isr2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x40400180 | isr3
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | isr4
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x002001C8 | last cmd Id
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | wait_event
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x0000FB6E | l2p_control
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000020 | l2p_duration
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | l2p_mhvalid
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | l2p_addr_match
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x0000008F | lmpm_pmg_sel
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x04120134 | timestamp
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00341828 | flow_handler
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Status: 0x00000100, count: 7
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000070 | ADVANCED_SYSASSERT
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | umac branchlink1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC0086AA4 | umac branchlink2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC008D83C | umac interruptlink1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC0083C90 | umac interruptlink2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000800 | umac data1
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC0083C90 | umac data2
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xDEADBEEF | umac data3
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000024 | umac major
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x9F0A2D68 | umac minor
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC088628C | frame pointer
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0xC088628C | stack pointer
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x0021010C | last host cmd
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: 0x00000000 | isr status reg
Jan 23 15:27:58 thinkpad kernel: iwlwifi 0000:04:00.0: Failed to send MAC context (action:1): -110

The errors go away when I remove the power saving settings, but wpa_supplicant seemed to carry on functioning regardless whereas iwd.service needs a restart after boot to get going again and would show the following in the journal:

iwd[594]: Error bringing interface 2 up: Connection timed out

I've had these settings enabled for months without a noticeable issue but have disabled them for now.

I had previously been running NetworkManager + wpa_supplicant so originally attempted to use NetworkManager + IWD, but encountered several issues:
1) I couldn't reliably scan for available networks using the NetworkManager GUI.
2) I had to use iwctl to create a file in /var/lib/iwd (as reported earlier in this thread) and only once this was done would NetworkManager connect. Given that I had already entered the ssid/passphrase into NetworkManager, I would have expected it to pass credentials to IWD once set as the wifi backend.
3) I couldn't get static IP's working through NetworkManager, only dhcp would get me connected and even then it was unreliable.

sjensen wrote:

damjan wrote:
@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".

On my (gnome) system, wpa_supplicant.service is started on boot even if both it and NetworkManager.service are disabled. It's dbus-activated by geoclue which is in turn dbus-activated by gnome-shell, so this may be gnome specific. Having wpa_supplicant.service running alongside iwd.service doesn't affect my network connectivity though. This makes sense to me since without NetworkManager.service running there's nothing asking the dbus version of wpa_supplicant to associate with any AP and so iwd.service is free to do so.

n8henrie wrote:

...my router conveniently(?) broadcasts my 2.4GHz and 5GHz networks under the same SSID (so some devices like my iPhone automatically use the 5 GHz when in range and switch to the 2.4GHz when farther away). But my new Arch box will only connect to the 2.4 with iwd, missing out on the 802.11ac speeds.

I have the same SSID for both 5GHz & 2.4GHz (for the same reasons) and IWD prefers the 5GHz band as one would expect. Perhaps this has changed recently. I'm using iwd 0.14-1.

Last edited by chr0mag (2019-01-24 03:51:29)

bjo · 2019-02-07 11:20:43

Switched to iwd as networkmanager backend yesterday and so far it works fine, connects really faster than wpa_supplicant.

Last edited by bjo (2019-02-07 11:20:54)

tim3dman · 2019-02-08 22:15:42

I'm having problems with NetworkManager and IWD not giving a connection after reboot. Then if I restart NetworkManager it all comes up ok. I have included systemctl status here

### After reboot

tim@t420 ~ % systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
           └─NetworkManager-ovs.conf
   Active: active (running) since Sat 2019-02-09 08:28:23 AEDT; 55s ago
     Docs: man:NetworkManager(8)
 Main PID: 467 (NetworkManager)
    Tasks: 3 (limit: 4915)
   Memory: 21.7M
   CGroup: /system.slice/NetworkManager.service
           └─467 /usr/bin/NetworkManager --no-daemon

Feb 09 08:28:23 t420 NetworkManager[467]: <info>  [1549661303.9925] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
Feb 09 08:28:23 t420 NetworkManager[467]: <info>  [1549661303.9941] manager: (enp0s25): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Feb 09 08:28:23 t420 NetworkManager[467]: <info>  [1549661303.9985] keyfile: add connection /var/run/NetworkManager/system-connections/Wired connection 1.nmco>
Feb 09 08:28:24 t420 NetworkManager[467]: <info>  [1549661304.0000] settings: (enp0s25): created default wired connection 'Wired connection 1'
Feb 09 08:28:24 t420 NetworkManager[467]: <info>  [1549661304.0046] device (enp0s25): state change: unmanaged -> unavailable (reason 'managed', sys-iface-stat>
Feb 09 08:28:24 t420 NetworkManager[467]: <info>  [1549661304.6487] manager: (wlp3s0): new 802.11 WiFi device (/org/freedesktop/NetworkManager/Devices/3)
Feb 09 08:28:24 t420 NetworkManager[467]: <info>  [1549661304.6791] ovsdb: Could not connect: No such file or directory
Feb 09 08:28:24 t420 NetworkManager[467]: <info>  [1549661304.6863] device (wlp3s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state>
Feb 09 08:28:28 t420 NetworkManager[467]: <info>  [1549661308.2437] agent-manager: req[0x7f3910002f00, :1.49/org.freedesktop.nm-applet/1000]: agent registered
Feb 09 08:28:30 t420 NetworkManager[467]: <info>  [1549661310.2680] manager: startup complete

## No network !!!

### After restart NetworkManager

tim@t420 ~ % systemctl status NetworkManager 
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
           └─NetworkManager-ovs.conf
   Active: active (running) since Sat 2019-02-09 08:30:33 AEDT; 3min 19s ago
     Docs: man:NetworkManager(8)
 Main PID: 892 (NetworkManager)
    Tasks: 7 (limit: 4915)
   Memory: 8.8M
   CGroup: /system.slice/NetworkManager.service
           ├─892 /usr/bin/NetworkManager --no-daemon
           ├─907 /usr/lib/nm-openvpn-service --bus-name org.freedesktop.NetworkManager.openvpn.Connection_2
           └─912 /usr/sbin/openvpn --remote au-melbourne.privateinternetaccess.com 1198 udp --comp-lzo adaptive --nobind --dev tun --cipher aes-128-cbc --auth>

Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8844] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed', sys>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8853] device (tun0): Activation: starting connection 'tun0' (94c77f1e-137b-43f1-a6c7-5ff723eb6b1>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8855] device (tun0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'ext>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8860] device (tun0): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8864] device (tun0): state change: config -> ip-config (reason 'none', sys-iface-state: 'externa>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8871] device (tun0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'exter>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8922] device (tun0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'ext>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8924] device (tun0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'ex>
Feb 09 08:30:36 t420 NetworkManager[892]: <info>  [1549661436.8955] device (tun0): Activation: successful, device activated.
Feb 09 08:30:39 t420 NetworkManager[892]: <info>  [1549661439.9221] manager: startup complete

## now full wifi network with vpn!

I've submitted a bug request because it seems to have just recently arisen in the last few days, beginning with only occasionally on startup, becoming worse till now every start.

Any ideas would be welcome.

Last edited by tim3dman (2019-02-08 22:16:50)

ua4000 · 2019-02-09 08:34:08

I had this too, in my case it was a low entropy pool during boot.
See the new section here, which I added now: https://wiki.archlinux.org/index.php/Iw … ter_reboot

n8henrie · 2019-02-11 22:06:22

chr0mag wrote:

I have the same SSID for both 5GHz & 2.4GHz (for the same reasons) and IWD prefers the 5GHz band as one would expect. Perhaps this has changed recently. I'm using iwd 0.14-1.

I reinstalled with iwd 0.14-1 and still have the same issue.

Running `iw [interface] scan`, I can see that my 5 GHz network has pretty good signal strength at -46.00 dBm, but my 2.4 GHz network (from the same router) has a stronger signal at -38 dBm ; looking at the code from https://git.kernel.org/pub/scm/network/ … can.c#n997 , it looks like the 5 GHz multiplier is only 1.1, so unless my 5 GHz gets down to -41 or lower it's not going to work. Which is tough, because it's coming from the same device, so any change in location or position is likely to affect both networks similarly.

Really would be helpful to be able to specify a bssid instead of ssid here; -46 is fine.

progandy · 2019-02-11 22:15:22

n8henrie, maybe ask the connman iwd people to improve 5G selection like choosing always 5GHz if the reception is better than -65 dBm? (At least allow setting that on a per-network basis or in the global configuration) You have a real world example of how their current implementation is flawed, so they might do something.

Edit: Accidentally wrote connman instead of iwd...

Last edited by progandy (2019-02-13 20:46:09)

n8henrie · 2019-02-11 22:22:21

I just joined the iwd mailing list and may chime in. I don't have connman installed, I think my issue is with iwd alone (see the source code linked).

chr0mag · 2019-02-12 00:36:08

n8henrie wrote:

chr0mag wrote:
I have the same SSID for both 5GHz & 2.4GHz (for the same reasons) and IWD prefers the 5GHz band as one would expect. Perhaps this has changed recently. I'm using iwd 0.14-1.
I reinstalled with iwd 0.14-1 and still have the same issue.
Running `iw [interface] scan`, I can see that my 5 GHz network has pretty good signal strength at -46.00 dBm, but my 2.4 GHz network (from the same router) has a stronger signal at -38 dBm ; looking at the code from https://git.kernel.org/pub/scm/network/ … can.c#n997 , it looks like the 5 GHz multiplier is only 1.1, so unless my 5 GHz gets down to -41 or lower it's not going to work. Which is tough, because it's coming from the same device, so any change in location or position is likely to affect both networks similarly.
Really would be helpful to be able to specify a bssid instead of ssid here; -46 is fine.

After watching this more closely the last couple of weeks I've noticed my laptop has ended up on the 2.4GHz band periodically too. Perhaps it occurs less frequently because of where I happen to sit in relation to my wireless router.

Have you seen IWD successfully move between bands based on the signal? My observation is that it stays with whichever band it connects to on boot and never changes. I have to restart iwd.service to get the bands to change. I haven't tested this in any kind of empirical way though.

Kampfpudding · 2019-02-12 05:50:39

chr0mag wrote:

Have you seen IWD successfully move between bands based on the signal? My observation is that it stays with whichever band it connects to on boot and never changes. I have to restart iwd.service to get the bands to change. I haven't tested this in any kind of empirical way though.

I am pretty sure I have. I don't have proof (yet) but I noticed my connection dropping for a few seconds every once in a while and occasional checks of iwconfig show different bands now and then.

I'll try to pay closer attention and will get back to you.

tim3dman · 2019-02-13 20:09:34

I have given up with NetworkManager. I can get it to start every time now but it was so slow to connect upside of 30sec, also I was getting slow network speeds, ugh. So I have bitten the bullet and gone all in with IWD, Systemd-Networkd and dhcpcd. It is working great with minimal setup and i get a very fast connect time after login of only a couple of seconds. I would like to have an indicator/applet of some kind but its not a deal breaker and I prefer not having to wait impatiently for a network. Now to sort out the vpn.

progandy · 2019-02-13 20:46:38

n8henrie wrote:

I just joined the iwd mailing list and may chime in. I don't have connman installed, I think my issue is with iwd alone (see the source code linked).

Yeah, sorry. I accidentally wrote connman instead of iwd.

tim3dman · 2019-02-18 01:11:04

Ok, Openvpn with PIA now working great with IWD, networkd and dhcpcd. I found that just putting a client.conf straight into /etc/openvpn/client/ is much easier than using the NM applet. Should've known.

jpegxguy · 2019-03-15 20:51:11

I have haveged enabled but I still get tim3dman's issue. Surely it's not an entropy thing... I'll check anyhow

Last edited by jpegxguy (2019-03-15 20:52:46)

Arch Linux

#101 2018-12-19 19:01:01

Re: The IWD thread

#102 2018-12-20 08:31:59

Re: The IWD thread

#103 2018-12-20 16:50:24

Re: The IWD thread

#104 2018-12-20 19:51:26

Re: The IWD thread

#105 2018-12-20 23:14:59

Re: The IWD thread

#106 2018-12-21 17:29:04

Re: The IWD thread

#107 2019-01-07 20:59:33

Re: The IWD thread

#108 2019-01-07 23:16:10

Re: The IWD thread

#109 2019-01-08 23:16:11

Re: The IWD thread

#110 2019-01-09 09:10:46

Re: The IWD thread

#111 2019-01-12 21:26:54

Re: The IWD thread

#112 2019-01-13 13:30:13

Re: The IWD thread

#113 2019-01-24 03:45:29

Re: The IWD thread

#114 2019-02-07 11:20:43

Re: The IWD thread

#115 2019-02-08 22:15:42

Re: The IWD thread

#116 2019-02-09 08:34:08

Re: The IWD thread

#117 2019-02-11 22:06:22

Re: The IWD thread

#118 2019-02-11 22:15:22

Re: The IWD thread

#119 2019-02-11 22:22:21

Re: The IWD thread

#120 2019-02-12 00:36:08

Re: The IWD thread

#121 2019-02-12 05:50:39

Re: The IWD thread

#122 2019-02-13 20:09:34

Re: The IWD thread

#123 2019-02-13 20:46:38

Re: The IWD thread

#124 2019-02-18 01:11:04

Re: The IWD thread

#125 2019-03-15 20:51:11

Re: The IWD thread

Board footer