Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf wrinkles
On Tue 22 Mar 2022 at 23:06:08 -0500, David Wright wrote: > (OTOH wicd appears to be able to detect that the interface has come > up, and to configure it, DHCP and all. In fact, I've found it more > reliable for wired interfaces as well, where I suspect glitches have > been caused by Powerline devices (ethernet through the mains power).) wicd-cli and wicd-curses are in experimental. A quick test here indicates either should install on bullseye. -- Brian.
Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf wrinkles
On Tue 22 Mar 2022 at 23:06:08 -0500, David Wright wrote: > On Sat 19 Mar 2022 at 10:18:49 (+1100), Charlie wrote: > > On Fri, 18 Mar 2022 14:32:40 + Brian wrote: > > > > > Regarding the installer: at present it provides an /e/n/i with wpa-* > > > lines. Changing wpasupplicant to iwd in d-i would requir some work. > > > No matter what the benefits of iwd are, I do not see that happening > > > in the near future. wpasupplicant remians as useful as it always has > > > been. > > It wasn't my intention to suggest displacing /e/n/i from the d-i. > I only mentioned it to point out (a) that installing iwd is a > conversion process if the d-i has been run wirelessly, and (b) that > I know next to nothing about configuring or running wpa_supplicant > because wicd just took care of it all. My remark was more aimed at the iwd advocates who see it as a replacement for the supplicant. Perhaps, in time, this might happen. I hope I have made it clear I am very happy with what iwd provides for my resource limited machines. > > Interesting, because I have always used wpasupplicant but since > > Bullseye has gone stable, have had this happen quite frequently: > > > > root@wilder:~# ifup wlp2s0 > > wpa_supplicant: /sbin/wpa_supplicant daemon failed to start > > run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return > > code 1 ifup: failed to bring up wlp2s0 > > It would be interesting to know why your wlp2s0 failed to come up. Your debugging technique should help Charlie. > > For one of my systems in particular, it fails because the wifi > happens to be hard-blocked when the system boots. It's very > simple to unblock it: just by pressing a button on the front edge > of the keyboard. (What a design cock-up.) I have never encountered this and haven't any way of testing. My initial thought would be to stick with using the button. > Unfortunately, using systemd-networkd/ifupdown/wpa_s (and > sysv/ifupdown/wpa_s in the past), it's not clear to me > who's responsible for cranking up the network after I've > pressed that button. I also haven't any clear idea. At a guess, a kernel module acer_wmi may be involved. 'modprobe -r acer_cli' could shed some light. (BTW wmi is Windows Management Instrumentation, I think). -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Wed 23 Mar 2022 at 13:06:12 (+0100), Stella Ashburne wrote: > From: "Brian" > > > > In truth, it is not a biggie for my intended use of iwd on some > > non-roaming machines, although it did break my /e/n/i. A couple of > > edits fixed that. > > Would you like to elaborate what stuff was broken in your /e/n/i ? You've already presented us with a stanza: # The primary network interface allow-hotplug wlp7s0 iface wlp7s0 inet static wpa-ssid JupiterRising wpa-psk (a long string of alphanumeric characters) address 192.168.1.99/24 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 1.1.1.1 8.8.8.8 Were you to install iwd on bullseye, udev would no longer rename the wlan0 interface to wlp7s0, and the stanza would break. What's unusual is that you don't have to configure iwd to run, only to install it. The problem is caused by the mere presence of the file /etc/systemd/network/80-iwd.link in package iwd. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
Mon cheri > Sent: Sunday, March 20, 2022 at 2:40 AM > From: "Brian" > To: debian-user@lists.debian.org > Subject: Re: iwd + systemd-networkd + resolvconf wrinkles > > In truth, it is not a biggie for my intended use of iwd on some > non-roaming machines, although it did break my /e/n/i. A couple of > edits fixed that. > Would you like to elaborate what stuff was broken in your /e/n/i ? Best regards. Stella
wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf wrinkles
On Sat 19 Mar 2022 at 10:18:49 (+1100), Charlie wrote: > On Fri, 18 Mar 2022 14:32:40 + Brian wrote: > > > Regarding the installer: at present it provides an /e/n/i with wpa-* > > lines. Changing wpasupplicant to iwd in d-i would requir some work. > > No matter what the benefits of iwd are, I do not see that happening > > in the near future. wpasupplicant remians as useful as it always has > > been. It wasn't my intention to suggest displacing /e/n/i from the d-i. I only mentioned it to point out (a) that installing iwd is a conversion process if the d-i has been run wirelessly, and (b) that I know next to nothing about configuring or running wpa_supplicant because wicd just took care of it all. > Interesting, because I have always used wpasupplicant but since > Bullseye has gone stable, have had this happen quite frequently: > > root@wilder:~# ifup wlp2s0 > wpa_supplicant: /sbin/wpa_supplicant daemon failed to start > run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return > code 1 ifup: failed to bring up wlp2s0 It would be interesting to know why your wlp2s0 failed to come up. For one of my systems in particular, it fails because the wifi happens to be hard-blocked when the system boots. It's very simple to unblock it: just by pressing a button on the front edge of the keyboard. (What a design cock-up.) Unfortunately, using systemd-networkd/ifupdown/wpa_s (and sysv/ifupdown/wpa_s in the past), it's not clear to me who's responsible for cranking up the network after I've pressed that button. (OTOH wicd appears to be able to detect that the interface has come up, and to configure it, DHCP and all. In fact, I've found it more reliable for wired interfaces as well, where I suspect glitches have been caused by Powerline devices (ethernet through the mains power).) So here's an illustration of the symptoms, starting with booting up in a hard-blocked state: $ sudo rfkill ID TYPE DEVICE SOFTHARD 0 wlan phy0 unblocked blocked $ $ systemctl status wpa_supplicant.service --no-pager -l ● wpa_supplicant.service - WPA supplicant Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-03-22 14:19:41 CDT; 11min ago Main PID: 464 (wpa_supplicant) Tasks: 1 (limit: 1108) Memory: 572.0K CPU: 15ms CGroup: /system.slice/wpa_supplicant.service └─464 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant Mar 22 14:19:35 acer systemd[1]: Starting WPA supplicant... Mar 22 14:19:41 acer wpa_supplicant[464]: Successfully initialized wpa_supplicant Mar 22 14:19:41 acer systemd[1]: Started WPA supplicant. $ So wpa_s is happy, and remains that way throughout. I won't quote it again. $ systemctl status ifup@wlp2s4.service --no-pager -l ● ifup@wlp2s4.service - ifup for wlp2s4 Loaded: loaded (/lib/systemd/system/ifup@.service; static) Active: failed (Result: exit-code) since Tue 2022-03-22 14:20:40 CDT; 10min ago Process: 372 ExecStart=/bin/sh -ec ifup --allow=hotplug wlp2s4; ifquery --state wlp2s4 (code=exited, status=1/FAILURE) Main PID: 372 (code=exited, status=1/FAILURE) CPU: 277ms Mar 22 14:20:40 acer sh[473]: No working leases in persistent database - sleeping. Mar 22 14:20:40 acer dhclient[473]: No working leases in persistent database - sleeping. Mar 22 14:20:40 acer avahi-autoipd(wlp2s4)[532]: SIOCSIFFLAGS failed: Operation not possible due to RF-kill Mar 22 14:20:40 acer root[534]: /etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd returned non-zero exit status 1 Mar 22 14:20:40 acer sh[540]: Error: Device for nexthop is not up. Mar 22 14:20:40 acer sh[536]: run-parts: /etc/network/if-up.d/avahi-autoipd exited with return code 2 Mar 22 14:20:40 acer systemd[1]: ifup@wlp2s4.service: Main process exited, code=exited, status=1/FAILURE Mar 22 14:20:40 acer sh[373]: ifup: failed to bring up wlp2s4 Mar 22 14:20:40 acer wpa_supplicant[429]: wlp2s4: CTRL-EVENT-TERMINATING Mar 22 14:20:40 acer systemd[1]: ifup@wlp2s4.service: Failed with result 'exit-code'. 3 $ It tried, failed, gave up. (The little 3 before the prompt is the value of $?) $ systemctl status systemd-networkd.service --no-pager -l ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-03-22 14:19:21 CDT; 11min ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 224 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1108) Memory: 3.3M CPU: 200ms CGroup: /system.slice/systemd-networkd.service └─224 /lib/systemd/systemd-networkd Mar 22 14:19:19 acer systemd[1]: Starting Network Service... Mar 22 14:19:21 acer systemd-networkd[224]: Enumeration completed Mar 22 14:19:21 acer systemd[1]: Started Network Service. Mar 22 14:19:27
Re: iwd + systemd-networkd + resolvconf wrinkles
On Sat 19 Mar 2022 at 10:12:54 -0500, Nicholas Geovanis wrote: > On Sat, Mar 19, 2022 at 7:33 AM Brian wrote: > > > On Fri 18 Mar 2022 at 20:57:38 +, Brian wrote: > > > > > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > > > > > [...] > > > > > > > Install iwd, and resolvconf if necessary. You may then need to reboot > > > > if the wifi interface has already been renamed by the kernel, ie if > > > > it's not wlan0. (With buster, there's a missing file that needs adding > > > > first; see below). > > > > > > It is systemd/udev that renames the interface. This is standard > > > procedure. iwd decides it knows better and, no matter what, does > > > it. I have never met this sort of behavior with wpasupplicant. > > > > > > So we will be more forceful and have > > > > > > net.ifnames=1 > > > > > > on GRUB's kernel command line. My choice is ignored by iwd. Why does > > > it not want an interface to be renamed by systemd/udev? > > > > Now sorted: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941652 > > > Surprised to see that took 25 months to sort out. > And a little surprised to read this written by M. Biebl on 4 Nov 2019: > "So the mere fact that iwd was installed changed the way the interfaces > are named. You don't actually have to enable/start iwd." > > because that does not follow the so-called "Principle of Least > Surprise". Upstrem iwd has decided on the direction it wants to take and, by closing the bug report, so has Debian. There seems little point in pursuing it further via those channels. I have limited skill with systemd but devised a service to rename the interface and integrate with ifupdown. [Unit] Description=Rename wlan0. Use ifupdown. Requires=iwd.service After=iwd.service [Service] ExecStartPre=/usr/bin/sleep 2 ExecStartPre=/sbin/ip link set wlan0 down ; /sbin/ip link set wlan0 name wlx74ea3a93adab ; /sbin/ip link set wlx74ea3a93adab up ExecStart=/sbin/ifup wlx74ea3a93adab [Install] WantedBy=multi-user.target /e/n/i can now be used as originally written. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Sat 19 Mar 2022 at 10:15:45 -0500, David Wright wrote: > On Fri 18 Mar 2022 at 20:57:38 (+), Brian wrote: > > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > > > [...] > > > > > Install iwd, and resolvconf if necessary. You may then need to reboot > > > if the wifi interface has already been renamed by the kernel, ie if > > > it's not wlan0. (With buster, there's a missing file that needs adding > > > first; see below). > > > > It is systemd/udev that renames the interface. > > Sorry, I was paraphrasing my notes and accidentally missed a bit out. > It should have said: "if the wifi interface has already been renamed > from the kernel's name", whereupon the id est makes sense. Indeed it does. > > This is standard procedure. > > I would say no more than that systemd and udev have reached a truce > on how and what to rename an interface to. :) > > iwd decides it knows better and, no matter what, does > > it. I have never met this sort of behavior with wpasupplicant. > > > > So we will be more forceful and have > > > > net.ifnames=1 > > > > on GRUB's kernel command line. My choice is ignored by iwd. Why does > > it not want an interface to be renamed by systemd/udev? > > https://iwd.wiki.kernel.org/interface_lifecycle > > explains iwd's philosophy on interfaces, and the last section covers > why it's not desirable for udev to attempt to rename them. The link you give, the Debian bug report and the README.Debian in unstable's iwd package all provide excellent information. In truth, it is not a biggie for my intended use of iwd on some non-roaming machines, although it did break my /e/n/i. A couple of edits fixed that. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Fri 18 Mar 2022 at 20:57:38 (+), Brian wrote: > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > [...] > > > Install iwd, and resolvconf if necessary. You may then need to reboot > > if the wifi interface has already been renamed by the kernel, ie if > > it's not wlan0. (With buster, there's a missing file that needs adding > > first; see below). > > It is systemd/udev that renames the interface. Sorry, I was paraphrasing my notes and accidentally missed a bit out. It should have said: "if the wifi interface has already been renamed from the kernel's name", whereupon the id est makes sense. > This is standard procedure. I would say no more than that systemd and udev have reached a truce on how and what to rename an interface to. > iwd decides it knows better and, no matter what, does > it. I have never met this sort of behavior with wpasupplicant. > > So we will be more forceful and have > > net.ifnames=1 > > on GRUB's kernel command line. My choice is ignored by iwd. Why does > it not want an interface to be renamed by systemd/udev? https://iwd.wiki.kernel.org/interface_lifecycle explains iwd's philosophy on interfaces, and the last section covers why it's not desirable for udev to attempt to rename them. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Fri 18 Mar 2022 at 14:08:36 (-0500), Nicholas Geovanis wrote: > On Thu, Mar 17, 2022, 11:57 PM David Wright wrote: > > On Thu 17 Mar 2022 at 12:12:28 (+), Thomas Pircher wrote > > > > > > Cool. If you just type resolvectl, it will show you which information it > > > got on each interface. > > > > This is machine F, where /etc/resolv.conf is a file, containing > > 192.168.1.1 : > > > > $ resolvectl > > Global > > Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported > > resolv.conf mode: foreign > > Current DNS Server: 192.168.1.1 > >DNS Servers: 192.168.1.1 > > > > Link 2 (enp2s2) > > Current Scopes: none > > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > > DNSSEC=no/unsupported > > > > Link 5 (wlp2s4) > > Current Scopes: LLMNR/IPv4 LLMNR/IPv6 > > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > > DNSSEC=no/unsupported > > $ host www.google.com > > www.google.com has address 142.250.138.105 > > www.google.com has address 142.250.138.103 > > www.google.com has address 142.250.138.106 > > www.google.com has address 142.250.138.99 > > www.google.com has address 142.250.138.104 > > www.google.com has address 142.250.138.147 > > www.google.com has IPv6 address 2607:f8b0:4000:80e::2004 > > $ host www.lionunicorn.co.uk > > www.lionunicorn.co.uk has address 149.255.60.149 > > $ > > > > Those responses were instantaneous. (I don't think I should expect > > resolvectl query to work here.) > > > > And this is machine R, with systemd-resolved running: > > > > $ ls -l /etc/resolv.conf > > lrwxrwxrwx [ … ] /etc/resolv.conf -> > > ../run/systemd/resolve/stub-resolv.conf > > $ resolvectl > > Global > >Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported > > resolv.conf mode: stub > > > > Link 2 (enp1s0) > > Current Scopes: none > > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > > DNSSEC=no/unsupported > > > > Link 4 (wlan0) > > Current Scopes: DNS LLMNR/IPv4 > > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS > > DNSSEC=no/unsupported > > Current DNS Server: 192.168.1.1 > >DNS Servers: 192.168.1.1 > > $ host www.google.com > > www.google.com has address 142.251.32.196 > > www.google.com has IPv6 address 2607:f8b0:4023:1002::63 > > www.google.com has IPv6 address 2607:f8b0:4023:1002::67 > > www.google.com has IPv6 address 2607:f8b0:4023:1002::93 > > www.google.com has IPv6 address 2607:f8b0:4023:1002::69 > > ;; connection timed out; no servers could be reached > > > > $ resolvectl query www.google.com > > www.google.com: 2607:f8b0:4000:805::2004 -- link: wlan0 > > 142.251.46.132 -- link: wlan0 > > > > Your machine F seems to resolve almost entirely IPv4 addresses for that > host. > But your machine R resolves almost exclusively IPv6 addresses for it. > > Could there be an identical hostname assigned to both IPv4 and IPv6 > interfaces? At this end? I only see: $ ip -4 a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 4: wlan0: mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 192.168.1.17/24 scope global noprefixroute wlan0 valid_lft forever preferred_lft forever $ ip -6 a 1: lo: mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host valid_lft forever preferred_lft forever $ and the usual autoconfigured link addresses. In my router, IPv6 is set to disabled. > In general you want DNS queries to resolve with less than 500msec network > latency. Above 1500 to 1700 msec the applications start breaking and > network timeouts are hit. > > Trimming the rest of your email... > > -- Information acquired via protocol DNS in 33.6ms. > > -- Data is authenticated: no > > . > > > > Cheers, > > David. > > Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Sat, Mar 19, 2022 at 7:33 AM Brian wrote: > On Fri 18 Mar 2022 at 20:57:38 +, Brian wrote: > > > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > > > [...] > > > > > Install iwd, and resolvconf if necessary. You may then need to reboot > > > if the wifi interface has already been renamed by the kernel, ie if > > > it's not wlan0. (With buster, there's a missing file that needs adding > > > first; see below). > > > > It is systemd/udev that renames the interface. This is standard > > procedure. iwd decides it knows better and, no matter what, does > > it. I have never met this sort of behavior with wpasupplicant. > > > > So we will be more forceful and have > > > > net.ifnames=1 > > > > on GRUB's kernel command line. My choice is ignored by iwd. Why does > > it not want an interface to be renamed by systemd/udev? > > Now sorted: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941652 Surprised to see that took 25 months to sort out. And a little surprised to read this written by M. Biebl on 4 Nov 2019: "So the mere fact that iwd was installed changed the way the interfaces are named. You don't actually have to enable/start iwd." because that does not follow the so-called "Principle of Least Surprise". Short story: iwd is faster than udev. > > -- > Brian. > >
Re: iwd + systemd-networkd + resolvconf wrinkles
On Fri 18 Mar 2022 at 20:57:38 +, Brian wrote: > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > [...] > > > Install iwd, and resolvconf if necessary. You may then need to reboot > > if the wifi interface has already been renamed by the kernel, ie if > > it's not wlan0. (With buster, there's a missing file that needs adding > > first; see below). > > It is systemd/udev that renames the interface. This is standard > procedure. iwd decides it knows better and, no matter what, does > it. I have never met this sort of behavior with wpasupplicant. > > So we will be more forceful and have > > net.ifnames=1 > > on GRUB's kernel command line. My choice is ignored by iwd. Why does > it not want an interface to be renamed by systemd/udev? Now sorted: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941652 Short story: iwd is faster than udev. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Fri, 18 Mar 2022 14:32:40 + Brian wrote: > Regarding the installer: at present it provides an /e/n/i with wpa-* > lines. Changing wpasupplicant to iwd in d-i would requir some work. > No matter what the benefits of iwd are, I do not see that happening > in the near future. wpasupplicant remians as useful as it always has > been. Interesting, because I have always used wpasupplicant but since Bullseye has gone stable, have had this happen quite frequently: root@wilder:~# ifup wlp2s0 wpa_supplicant: /sbin/wpa_supplicant daemon failed to start run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1 ifup: failed to bring up wlp2s0 So may have to look at iwd? Charlie -- Registered Linux User:- 329524 *** There is no exercise better for the heart than reaching down and lifting people up.-- John Holmes *** Debian GNU/Linux - Magic indeed. -
Re: iwd + systemd-networkd + resolvconf wrinkles
On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: [...] > Install iwd, and resolvconf if necessary. You may then need to reboot > if the wifi interface has already been renamed by the kernel, ie if > it's not wlan0. (With buster, there's a missing file that needs adding > first; see below). It is systemd/udev that renames the interface. This is standard procedure. iwd decides it knows better and, no matter what, does it. I have never met this sort of behavior with wpasupplicant. So we will be more forceful and have net.ifnames=1 on GRUB's kernel command line. My choice is ignored by iwd. Why does it not want an interface to be renamed by systemd/udev? -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu, Mar 17, 2022, 11:57 PM David Wright wrote: > On Thu 17 Mar 2022 at 12:12:28 (+), Thomas Pircher wrote > > > > Cool. If you just type resolvectl, it will show you which information it > > got on each interface. > > This is machine F, where /etc/resolv.conf is a file, containing > 192.168.1.1 : > > $ resolvectl > Global > Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported > resolv.conf mode: foreign > Current DNS Server: 192.168.1.1 >DNS Servers: 192.168.1.1 > > Link 2 (enp2s2) > Current Scopes: none > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > > Link 5 (wlp2s4) > Current Scopes: LLMNR/IPv4 LLMNR/IPv6 > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > $ host www.google.com > www.google.com has address 142.250.138.105 > www.google.com has address 142.250.138.103 > www.google.com has address 142.250.138.106 > www.google.com has address 142.250.138.99 > www.google.com has address 142.250.138.104 > www.google.com has address 142.250.138.147 > www.google.com has IPv6 address 2607:f8b0:4000:80e::2004 > $ host www.lionunicorn.co.uk > www.lionunicorn.co.uk has address 149.255.60.149 > $ > > Those responses were instantaneous. (I don't think I should expect > resolvectl query to work here.) > > And this is machine R, with systemd-resolved running: > > $ ls -l /etc/resolv.conf > lrwxrwxrwx [ … ] /etc/resolv.conf -> > ../run/systemd/resolve/stub-resolv.conf > $ resolvectl > Global >Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported > resolv.conf mode: stub > > Link 2 (enp1s0) > Current Scopes: none > Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > > Link 4 (wlan0) > Current Scopes: DNS LLMNR/IPv4 > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS > DNSSEC=no/unsupported > Current DNS Server: 192.168.1.1 >DNS Servers: 192.168.1.1 > $ host www.google.com > www.google.com has address 142.251.32.196 > www.google.com has IPv6 address 2607:f8b0:4023:1002::63 > www.google.com has IPv6 address 2607:f8b0:4023:1002::67 > www.google.com has IPv6 address 2607:f8b0:4023:1002::93 > www.google.com has IPv6 address 2607:f8b0:4023:1002::69 > ;; connection timed out; no servers could be reached > > $ resolvectl query www.google.com > www.google.com: 2607:f8b0:4000:805::2004 -- link: wlan0 > 142.251.46.132 -- link: wlan0 > Your machine F seems to resolve almost entirely IPv4 addresses for that host. But your machine R resolves almost exclusively IPv6 addresses for it. Could there be an identical hostname assigned to both IPv4 and IPv6 interfaces? In general you want DNS queries to resolve with less than 500msec network latency. Above 1500 to 1700 msec the applications start breaking and network timeouts are hit. Trimming the rest of your email... -- Information acquired via protocol DNS in 33.6ms. > -- Data is authenticated: no > . > > Cheers, > David. >
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 23:40:28 -0500, David Wright wrote: > On Wed 16 Mar 2022 at 22:40:07 (+), Brian wrote: [...] > > OTOH, the Debian iwd package > > does not provide any integration with ifupdown > > Does iwd need ifupdown at all? It seems to be able to configure the > interface itself. No it doesn't and its DHCP inclusion plus the ability to use a static IP are nice touches. All-in-all I could live with that if it was my only requirement. However, ifupdown integrates with guessnet and I have /e/n/i set up for that. wpasupplicant is integrated with /e/n/i, so I have what is quite a neat and useful roaming setup. The scripts doing this are from Debian/Ubuntu developers, not from upstream. Perhas iwd will acquire something similar in the course of time. Regarding the installer: at present it provides an /e/n/i with wpa-* lines. Changing wpasupplicant to iwd in d-i would requir some work. No matter what the benefits of iwd are, I do not see that happening in the near future. wpasupplicant remians as useful as it always has been. > > and no one as get has > > published a GUI frontend for it. > > I get the impression that that would be seen as bloat. No matter how straightforward and easy you and I see iwctl to be, there are users who would benefit from such a frontend. One such is iwgtk, which is not in Debian. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 23:39:39 -0500, David Wright wrote: > On Thu 17 Mar 2022 at 14:50:06 (+), Brian wrote: > > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > > > [...] > > > > > By the end of all this, the link should be working, and a file > > > like this will have been written (that only root can see): > > > > > > # cat /var/lib/iwd/YourSSID.psk > > > [Security] > > > PreSharedKey=abdcef0123456789…abdcef0123456789…abdcef0123456789 > > > Passphrase=yoursecretpassphrase > > > # > > > > However, brian (who is not in the netdev group) can do > > > > iwctl known-networks YourSSID forget > > > > and /var/lib/iwd/YourSSID.psk is deleted. > > > > This user can also successfully execute > > > > iwctl station wlan0 connect YourSSID > > > > to bring about association with a WAP. Neither should be possible. > > I have /read/ that security is handled through D-Bus, but I haven't > followed this up because the above doesn't present a problem here. Perhaps a problem would arise when there are untrusted users on the machine. Having the network connection destroyed, accidentally or not, is not my idea of fun. > For example, /etc/dbus-1/system.d/org.freedesktop.ModemManager1.conf > seems to be aimed at controlling a modem, where a user might otherwise > be able to spend real money at someone else's expense. I guess Debian > might provide something like that. > > I /imagine/ that such a facility could be quite fine-grained, unlike > plain netdev permissions. For example, allowing "connect"ions like the > above, but only to pre-defined SSIDs, and disallowing reconfigurations > like the "forget" above. > > Then an /etc/default/iwd might define the privileged usernames for > each operation, or point to a file defining such. My uderstanding is that access to hardware should be handled by ACLs (preferably) or group membership. For example, an ACL is used for my audio card and scanner. wpasupplicant uses netdev group membership. The idea of devolving such a facility to a message bus service does not seem like the right path to take. BTW, iwd in bullseye has dbus as a recommended package. It would be interesting to know what part of iwd works without dbus. A quick test here has iwd quitting when the dbus service is stopped. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Wed 16 Mar 2022 at 22:40:07 (+), Brian wrote: > > iwd Highly functional & low resource & DHCP client. > > Thank you for your informative and useful account of iwd. Apologies > if my snipping is too brutal :). > > It is almost a no-brainer to eastablish a wireless link with iwd. I > think the single command > > iwctl station wlan0 connect YourSSI > > should do it. Yes, assuming you know your SSID (and everything has worked along the way). > Having said that, it is interesting that a user of a > presently defunct graphical GUI would choose to take this path. Me? A GUI? To set up a network? Never have done yet. Besides, I've set up wicd on low-resource machines in the past that never had X running on them. That's the beauty of having a TUI. > The projected demise of wpasupplicant is premature. For my my use it > perfecactly fits my needs. The main advantage ove iwd is that it > integrates very nicely with ifupdown with staticc and roaming setups. > wpsgui is also a very assistive utility. I've not had to tell wpasupplicant anything before, because I only ran ifupdown+wpasupplicant under the original d-i configuration, and then just until I installed wicd. The GUI looks as though it's simple to use, but I prefer to be able to set up networking in the absence of X. The CLI has completion, like iwd does, which is as well, because the help command is difficult to use unless you already have some idea of the command vocabulary. I'm not sure why I could run the GUI as a user, but not the CLI: Could not connect to wpa_supplicant: (nil) - re-trying Perhaps there's something I'm meant to set somewhere. > OTOH, the Debian iwd package > does not provide any integration with ifupdown Does iwd need ifupdown at all? It seems to be able to configure the interface itself. > and no one as get has > published a GUI frontend for it. I get the impression that that would be seen as bloat. > However, your post inspired me. The installed size of iwd is a fifth > that of wpasuppicant. I have machines with only 1 GB of disk space. > That is a significant saving. So I have ended up with iwd on one of > them and, with a static stanza in /en/i, can integrate with ifupdown > to some degree. Happy camping, as they say :). > > Thanks again for giving me some incentive and a bit of fun. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 14:50:06 (+), Brian wrote: > On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: > > [...] > > > By the end of all this, the link should be working, and a file > > like this will have been written (that only root can see): > > > > # cat /var/lib/iwd/YourSSID.psk > > [Security] > > PreSharedKey=abdcef0123456789…abdcef0123456789…abdcef0123456789 > > Passphrase=yoursecretpassphrase > > # > > However, brian (who is not in the netdev group) can do > > iwctl known-networks YourSSID forget > > and /var/lib/iwd/YourSSID.psk is deleted. > > This user can also successfully execute > > iwctl station wlan0 connect YourSSID > > to bring about association with a WAP. Neither should be possible. I have /read/ that security is handled through D-Bus, but I haven't followed this up because the above doesn't present a problem here. For example, /etc/dbus-1/system.d/org.freedesktop.ModemManager1.conf seems to be aimed at controlling a modem, where a user might otherwise be able to spend real money at someone else's expense. I guess Debian might provide something like that. I /imagine/ that such a facility could be quite fine-grained, unlike plain netdev permissions. For example, allowing "connect"ions like the above, but only to pre-defined SSIDs, and disallowing reconfigurations like the "forget" above. Then an /etc/default/iwd might define the privileged usernames for each operation, or point to a file defining such. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 09:33:30 (-0400), Stefan Monnier wrote: > > However, your post inspired me. The installed size of iwd is a fifth > > that of wpasuppicant. > > I'm curious what is the explanation for that size difference, since from > a casual look it appears that iwd provides pretty much a superset of the > functionality of wpa-supplicant (more specifically the extra feature is > DHCP client). Perhaps because wpasupplicant, accoring to wikipedia, supports Linux, FreeBSD, NetBSD, QNX, AROS, Microsoft Windows, Solaris, OS/2 (including ArcaOS and eComStation) and Haiku. […] it also implements WPA and older wireless LAN security protocols. OTOH iwd supports Linux. And that's ignoring the "core goal of the project […] to optimize resource utilization: storage, runtime memory and link-time costs. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 12:12:28 (+), Thomas Pircher wrote: > David Wright wrote: > > As I said, I tried that. > > Ack. I must have glossed over that. Sorry. The rest of my mail stands, > though. > > > > You can configure various settings for the DNS resolver in your > > > systemd-networkd setting and in /etc/systemd/resolved.conf. > > > > Like what? > > Full description here: > https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCPv4%5D%20Section%20Options > https://www.freedesktop.org/software/systemd/man/resolved.conf.html Yes, I read those, but I can see nothing to profitably change. > But what I find useful is to be able to select per interface if DNS > should be used from the DHCP server, if there is a clash. > I also ended up disabling DNSSEC on some machines due to a broken > server. I am assuming that I don't have that problem at home. As for on-the-road, I'm not sure I'd be capable of diagnosing such problems. > > > On bookworm you also have the resolvectl tool, which helps debugging DNS > > > issues. > > > > And bullseye has that too. I don't really know how to use it. > > Cool. If you just type resolvectl, it will show you which information it > got on each interface. This is machine F, where /etc/resolv.conf is a file, containing 192.168.1.1 : $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 Link 2 (enp2s2) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 5 (wlp2s4) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported $ host www.google.com www.google.com has address 142.250.138.105 www.google.com has address 142.250.138.103 www.google.com has address 142.250.138.106 www.google.com has address 142.250.138.99 www.google.com has address 142.250.138.104 www.google.com has address 142.250.138.147 www.google.com has IPv6 address 2607:f8b0:4000:80e::2004 $ host www.lionunicorn.co.uk www.lionunicorn.co.uk has address 149.255.60.149 $ Those responses were instantaneous. (I don't think I should expect resolvectl query to work here.) And this is machine R, with systemd-resolved running: $ ls -l /etc/resolv.conf lrwxrwxrwx [ … ] /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp1s0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 4 (wlan0) Current Scopes: DNS LLMNR/IPv4 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 $ host www.google.com www.google.com has address 142.251.32.196 www.google.com has IPv6 address 2607:f8b0:4023:1002::63 www.google.com has IPv6 address 2607:f8b0:4023:1002::67 www.google.com has IPv6 address 2607:f8b0:4023:1002::93 www.google.com has IPv6 address 2607:f8b0:4023:1002::69 ;; connection timed out; no servers could be reached $ resolvectl query www.google.com www.google.com: 2607:f8b0:4000:805::2004 -- link: wlan0 142.251.46.132 -- link: wlan0 -- Information acquired via protocol DNS in 33.6ms. -- Data is authenticated: no $ resolvectl query www.lionunicorn.co.uk www.lionunicorn.co.uk: resolve call failed: Connection timed out $ Here, host's substantive response was immediate, but I had to wait for the prompt to return. > You can also debug your slow queries by using "resolvectl query > google.com". It will show you which interface the query goes out on and > how long it took to get the response. The attached file has the date, hour, hostname, systemd-resolved and PID removed, and it pertains to the www.lionunicorn.co.uk query above. Perhaps this would pinpoint a problem. > > There seem to be timeouts involved in most cases, so time ping -c 1 foo > > will typically take 15sec, and host lookups will take 10 or 20sec. > > That is far too long. A wild guess: you may have received a bunch of > unresponsive DNS servers from your DHCP reply, and your machine is > trying to use them in turn, until it finds a working server? > DNSSEC problem? Or do you get IPv6 addresses for the DNS server, but > they are not reachable? > > You can try debugging this with the resolvectl tool, to find out the > list of the servers. Then query them with the dig tool from the > bind9-dnsutils package: > > dig google.com @8.8.8.8 > > Replace the IP address in @8.8.8.8 with the an IP from the output of > resolvectl. This response is immediate on R: $ dig www.lionunicorn.co.uk @192.168.1.1 ; <<>> DiG 9.16.22-Debian <<>> www.lionunicorn.co.uk @192.168.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30004 ;; flags: qr rd ra; QUERY: 1, ANSWER:
Re: iwd + systemd-networkd + resolvconf wrinkles
I just wanted to say thanks for the post and instructions. I've been using IWD on a different distro and wish that Debian will someday adopt it as its default.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Sun 13 Mar 2022 at 20:04:06 -0500, David Wright wrote: [...] > By the end of all this, the link should be working, and a file > like this will have been written (that only root can see): > > # cat /var/lib/iwd/YourSSID.psk > [Security] > PreSharedKey=abdcef0123456789…abdcef0123456789…abdcef0123456789 > Passphrase=yoursecretpassphrase > # However, brian (who is not in the netdev group) can do iwctl known-networks YourSSID forget and /var/lib/iwd/YourSSID.psk is deleted. This user can also successfully execute iwctl station wlan0 connect YourSSID to bring about association with a WAP. Neither should be possible. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Thu 17 Mar 2022 at 09:33:30 -0400, Stefan Monnier wrote: > > However, your post inspired me. The installed size of iwd is a fifth > > that of wpasuppicant. > > I'm curious what is the explanation for that size difference, since from > a casual look it appears that iwd provides pretty much a superset of the > functionality of wpa-supplicant (more specifically the extra feature is > DHCP client). Specifically, I do not know. The executables are 3,272,960 and 448,364 (iwd). -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
David Wright wrote: As I said, I tried that. Ack. I must have glossed over that. Sorry. The rest of my mail stands, though. You can configure various settings for the DNS resolver in your systemd-networkd setting and in /etc/systemd/resolved.conf. Like what? Full description here: https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCPv4%5D%20Section%20Options https://www.freedesktop.org/software/systemd/man/resolved.conf.html But what I find useful is to be able to select per interface if DNS should be used from the DHCP server, if there is a clash. I also ended up disabling DNSSEC on some machines due to a broken server. On bookworm you also have the resolvectl tool, which helps debugging DNS issues. And bullseye has that too. I don't really know how to use it. Cool. If you just type resolvectl, it will show you which information it got on each interface. You can also debug your slow queries by using "resolvectl query google.com". It will show you which interface the query goes out on and how long it took to get the response. There seem to be timeouts involved in most cases, so time ping -c 1 foo will typically take 15sec, and host lookups will take 10 or 20sec. That is far too long. A wild guess: you may have received a bunch of unresponsive DNS servers from your DHCP reply, and your machine is trying to use them in turn, until it finds a working server? DNSSEC problem? Or do you get IPv6 addresses for the DNS server, but they are not reachable? You can try debugging this with the resolvectl tool, to find out the list of the servers. Then query them with the dig tool from the bind9-dnsutils package: dig google.com @8.8.8.8 Replace the IP address in @8.8.8.8 with the an IP from the output of resolvectl. # resolvectl query smtp.lionunicorn.co.uk answered in 57.6 secs. # resolvectl query lionunicorn.co.uk failed with: lionunicorn.co.uk: resolve call failed: Query timed out On my machine I get: # resolvectl query smtp.lionunicorn.co.uk smtp.lionunicorn.co.uk: 149.255.60.149 -- link: vlan3512 -- Information acquired via protocol DNS in 31.0ms. -- Data is authenticated: no Try running the queries with dig, as described above. The debug output is difficult to interpret, though I did notice that it was reporting "cache misses" repeatedly on the same address (but there must be some caching going on, because there was an occasional hit being reported). It really sounds like some of the DNS servers are not reachable. The idea of "debugging DNS issues" doesn't exactly thrill me. I'm imagining a scenario where I'm sitting in an airport or motel room, having managed to make a connection with iwd and negotiate their captive portal or whatever, and then run into /this/ problem. Ack, fully understand. I do think there is something broken in your network setup or the server that gives you the list of DNS server is not configured correctly. If you have found a way to fix the problem, or work around it, by using another tool, and this works for you, all the power to you. :-) Cheers Thomas
Re: iwd + systemd-networkd + resolvconf wrinkles
> iwd Highly functional & low resource & DHCP client. Thank you for your informative and useful account of iwd. Apologies if my snipping is too brutal :). It is almost a no-brainer to eastablish a wireless link with iwd. I think the single command iwctl station wlan0 connect YourSSI should do it. Having said that, it is interesting that a user of a presently defunct graphical GUI would choose to take this path. The projected demise of wpasupplicant is premature. For my my use it perfecactly fits my needs. The main advantage ove iwd is that it integrates very nicely with ifupdown with staticc and roaming setups. wpsgui is also a very assistive utility. OTOH, the Debian iwd package does not provide any integration with ifupdown and no one as get has published a GUI frontend for it. However, your post inspired me. The installed size of iwd is a fifth that of wpasuppicant. I have machines with only 1 GB of disk space. That is a significant saving. So I have ended up with iwd on one of them and, with a static stanza in /en/i, can integrate with ifupdown to some degree. Happy camping, as they say :). Thanks again for giving me some incentive and a bit of fun. -- Brian.
Re: iwd + systemd-networkd + resolvconf wrinkles
On Mon 14 Mar 2022 at 07:15:12 (+), Thomas Pircher wrote: > David Wright wrote: > > I was casting round for a simple way to run iwd + resolvconf + > > systemd-networkd as replacement. > > I run a similar setup, with iwd, systemd-networkd and systemd-resolved. > This has been working without problems on my host for for quite a while > now. As I said, I tried that. > Make a copy of your /etc/resolv.conf file, No point, as there's nothing specific in it, but just what gets sent by DHCP from the router. > then enable and restart the > systemd-resolved service. Finally link the /etc/resolv.conf file to > either /run/systemd/resolve/resolv.conf or > /run/systemd/resolve/stub-resolv.conf. I use the latter: > > # ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 Jun 28 2020 > /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf (It was created for me.) So, to summarise, I have a three-line /var/lib/iwd/mySSID.psk (Security, PSK, passphrase), a two-line /etc/iwd/main.conf (General, EnableNetworkConfiguration=true), and nothing else: no overrides, no resolvconf package, and no cat5 cable. > You can configure various settings for the DNS resolver in your > systemd-networkd setting and in /etc/systemd/resolved.conf. Like what? > On bookworm you also have the resolvectl tool, which helps debugging DNS > issues. And bullseye has that too. I don't really know how to use it. There seem to be timeouts involved in most cases, so time ping -c 1 foo will typically take 15sec, and host lookups will take 10 or 20sec. That's 10sec, or 20sec, depending on whether the message ;; connection timed out; no servers could be reached is emitted once or twice. I ran resolvectl log-level debug and triedresolvectl query foo on a few addresses. They were even slower, eg: # resolvectl query smtp.lionunicorn.co.uk answered in 57.6 secs. # resolvectl query lionunicorn.co.uk failed with: lionunicorn.co.uk: resolve call failed: Query timed out The debug output is difficult to interpret, though I did notice that it was reporting "cache misses" repeatedly on the same address (but there must be some caching going on, because there was an occasional hit being reported). I also noticed that debug output carries on being emitted after the actual query has finished and returned to a bash prompt; for something like another minute, achieving nothing (repeating a query does it all over again). Everything is comparatively instantaneous when using resolvconf, which is why I chose to continue using it. The idea of "debugging DNS issues" doesn't exactly thrill me. I'm imagining a scenario where I'm sitting in an airport or motel room, having managed to make a connection with iwd and negotiate their captive portal or whatever, and then run into /this/ problem. Cheers, David.
Re: iwd + systemd-networkd + resolvconf wrinkles
David Wright wrote: I was casting round for a simple way to run iwd + resolvconf + systemd-networkd as replacement. I run a similar setup, with iwd, systemd-networkd and systemd-resolved. This has been working without problems on my host for for quite a while now. Make a copy of your /etc/resolv.conf file, then enable and restart the systemd-resolved service. Finally link the /etc/resolv.conf file to either /run/systemd/resolve/resolv.conf or /run/systemd/resolve/stub-resolv.conf. I use the latter: # ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 Jun 28 2020 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf You can configure various settings for the DNS resolver in your systemd-networkd setting and in /etc/systemd/resolved.conf. On bookworm you also have the resolvectl tool, which helps debugging DNS issues. Thomas
