iwd + systemd-networkd + resolvconf wrinkles

[David Wright]

This might be considered a reply to:
https://lists.debian.org/debian-user/2022/02/msg00118.html
or the couple of threads around:
https://lists.debian.org/debian-user/2021/09/msg01052.html
or even:
https://lists.debian.org/debian-user/2019/04/msg01013.html

Now that wicd has gone (no Python2), and allegedly wpasupplicant
is not long for this world, I was casting round for a simple way
to run iwd + resolvconf + systemd-networkd as replacement.

iwd Highly functional & low resource & DHCP client.
Minimally documented¹, only does wifi (no wired)

resolvconf Should configure varying nameservers into
resolv.conf for different networks/interfaces.

systemd-networkd Runs the wired interfaces.

As the debian-installer installs wpasupplicant, this is
necessarily a conversion process, outlined briefly here,
a combination of howto and diary:

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

$ systemctl --now disable wpa_supplicant.service
$ systemctl --now enable iwd.service

(Those commands are quieter when done as root, or with sudo.)

$ iwctl
Waiting for IWD to start...
[iwd]#

This section is interactive. Some of the commands here are just to
confirm its actions and replies. Don't type the "iwctl" before each
command: it's only needed when typing into a bash prompt, as opposed
to the [iwd]# prompt².

iwctl adapter list
iwctl adapter phy0 show
iwctl device list
iwctl device wlan0 show
iwctl station list
iwctl station wlan0 show
iwctl station wlan0 get-networks
iwctl station wlan0 connect YourSSID
Type the network passphrase for Cascade5G psk.
Passphrase: *********************************
iwctl known-networks list
iwctl station wlan0 show

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
#

The other file that I have created on my bullseye is:

# /etc/iwd/main.conf
[General]
# use DHCP client built into iwd:
EnableNetworkConfiguration=true
# for use only when travelling:
#AddressRandomization=network
[Network]
# systemd-resolved would otherwise default:
NameResolvingService=resolvconf
#

That should be enough to get connected to a router via wifi
as soon as it boots up, with DHCP supplying an IP address, and
contents for resolv.conf. However, the latter does not happen
until I make one other change.

The problem appears to be that iwd doesn't have necessary
permission to mess with /run/resolvconf and /etc/resolv.conf.
AIUI it's not file permissions, but internal policy within
systemd. The simplest fix seems to be:³

# cp -ip /lib/systemd/system/iwd.service /etc/systemd/system/

# edit /etc/systemd/system/iwd.service and add these two lines
to the end of the [Service] section:

RuntimeDirectory=resolvconf
ReadWritePaths=/etc

The error being eliminated can be seen in /var/log/daemon.log:

iwd[…]: /usr/sbin/resolvconf: 57: cannot create
/run/resolvconf/run-lock: Read-only file system
iwd[…]: resolve: /usr/sbin/resolvconf exited with status (512).

After fixing and rebooting, you should get something like:

/run/resolvconf/:
-rw-r--r-- 1 root root 0 enable-updates
drwxr-xr-x 2 root root 60 interface
-rw-r--r-- 1 root root 298 resolv.conf
-rw-r--r-- 1 root root 0 run-lock

/run/resolvconf/interface:
-rw-r--r-- 1 root root 23 wlan0.dns
$

Note that the comments in /run/resolvconf/resolv.conf are
misleading, and assume that we're using systemd-resolved.
Running "resolvectl status", as suggested there, gives:
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

Why don't I use systemd-resolved? (a) I don't understand its
documentation, nor its diagnostic output, and (b) it was slow
resolving, say, google.com, and threw an error rather than
resolve www.google.com. Not a lot of use to me.

If you try this on buster, which has a very old version of iwd,
you need to create this file to prevent the kernel from renaming
the wifi interface, which can cause a race with iwd.

# /etc/systemd/network/80-iwd.link
[Match]
Type=wlan
[Link]
# prevent udev from renaming this interface:
NamePolicy=keep kernel
#

Also, the EnableNetworkConfiguration=true doesn't appear to
have been implemented on buster's version 0.14, so the IP
configuration has to be left up to systemd-networkd with:

# cat /etc/systemd/network/80-wifi-station.network
[Match]
Name=wlan0
[Network]
DHCP=yes
#

(/usr/lib/systemd/network/80-wifi-station.network.example is
taken from bullseye, but simplified.) However, I haven't seen
any nameservers being added to resolv.conf in buster.

Back in bullseye, I can simultaneously configure a static interface
with the same IP address on the wired ethernet interface, which is
a useful backup for my LAN in the absence of wifi.

However, I haven't yet worked out how to make systemd-networkd
talk to resolvconf (whilst sharing with iwd) so that the wired
interface can resolve Internet addresses.

This thread is covering a similar lack when using NetworkManager:
https://lists.debian.org/debian-user/2022/03/msg00484.html
and I'm currently looking through references in:
https://unix.stackexchange.com/questions/517919/systemd-way-to-disable-wlan-if-wired-network-is-available

Because all my computers can intercommunicate on my LAN using
/etc/hosts, it's not too much of an issue at present. I can
even update/upgrade through my local apt-cacher-ng.

¹ virtually none in buster.

² If you want to log your conversation, it's easiest to run each
iwctl command separately at a shell prompt and copy/paste the
output. Using script on an interactive session is not the way to go.

³ Don't alter anything in /lib, but override and supplement things
in /etc.

Cheers,
David.

[Thomas Pircher]

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

[David Wright]

On Mon 14 Mar 2022 at 07:15:12 (+0000), 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 tried resolvectl 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.

[Brian]

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

[Thomas Pircher]

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

[Stefan Monnier]

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


Stefan

[Brian]

Specifically, I do not know. The executables are 3,272,960 and
448,364 (iwd).

--
Brian.

[Brian]

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.

[RP]

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.

[David Wright]

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.

[David Wright]

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.

[David Wright]

On Wed 16 Mar 2022 at 22:40:07 (+0000), 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.

[David Wright]

On Thu 17 Mar 2022 at 12:12:28 (+0000), 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: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.lionunicorn.co.uk. IN A

;; ANSWER SECTION:
www.lionunicorn.co.uk. 10800 IN A 149.255.60.149

;; Query time: 191 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Mar 17 23:03:37 CDT 2022
;; MSG SIZE rcvd: 66

$

In case of interest, the query time (191, 195 msec) on machine R is
consistently slower than machine F (28, 44 msec). (R is a /much/
faster machine than F, being 10 years younger.)

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

Silly me: I used www this time, instead of smtp. But I just checked,
and it resolves the same address in the same time. It's all just
pointing at cloud204.unlimitedwebhosting.co.uk in reality.

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

The same server is being used by machines F and R, and I could have
equally well set the two laptops up in the opposite configuration.
So something has to be wrong in the configuration of R. The nameserver
address of 127.0.0.53 in R's /etc/resolv.conf goes into one end of
systemd-resolved, and should come out at the other end as 192.168.1.1,
the sole nameserver, residing at the edge of my LAN. What goes on
inside systemd-resolved's stomach is a deep mystery.

> 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. :-)

Yes, either resolvconf (for travel), or a fixed 192.168.1.1 suffices
(at home).

Cheers,
David.

[Stefan Monnier]

David Wright [2022-03-17 23:39:16] wrote:
> 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.

`iwd` also supports WPA, as far I can tell.

> And that's ignoring the "core goal of the project […] to optimize
> resource utilization: storage, runtime memory and link-time costs.

Indeed I saw that, but unless wpa-supplicant was written "carelessly"
it's surprising that its code be so much bigger just by "being careful"
and dropping compatibility with other OSes.


Stefan

[Brian]

On Thu 17 Mar 2022 at 23:39:39 -0500, David Wright wrote:

> On Thu 17 Mar 2022 at 14:50:06 (+0000), 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.

[Brian]

On Thu 17 Mar 2022 at 23:40:28 -0500, David Wright wrote:

> On Wed 16 Mar 2022 at 22:40:07 (+0000), 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.

[Nicholas Geovanis]

On Thu, Mar 17, 2022, 11:57 PM David Wright <deb...@lionunicorn.co.uk> wrote:

On Thu 17 Mar 2022 at 12:12:28 (+0000), Thomas Pircher wrote
>

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.

[Brian]

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.

[Charlie]

On Fri, 18 Mar 2022 14:32:40 +0000
Brian <ad...@cityscape.co.uk> 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.

-----------------------------------------------------

[Brian]

Now sorted:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941652

Short story: iwd is faster than udev.

--
Brian.

[David Wright]

On Fri 18 Mar 2022 at 14:08:36 (-0500), Nicholas Geovanis wrote:

At this end? I only see:

$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <LOOPBACK,UP,LOWER_UP> 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.

[David Wright]

On Fri 18 Mar 2022 at 20:57:38 (+0000), 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.

[Nicholas Geovanis]

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

[Brian]

On Sat 19 Mar 2022 at 10:15:45 -0500, David Wright wrote:

> On Fri 18 Mar 2022 at 20:57:38 (+0000), 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.

[Brian]

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.

[David Wright]

On Sat 19 Mar 2022 at 10:18:49 (+1100), Charlie wrote:

> On Fri, 18 Mar 2022 14:32:40 +0000 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&wpa 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 SOFT HARD
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 if...@wlp2s4.service --no-pager -l
● if...@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]: if...@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]: if...@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 acer systemd-networkd[224]: eth0: Interface name change detected, eth0 has been renamed to wlp2s4.
Mar 22 14:19:28 acer systemd-networkd[224]: wlp2s4: Could not bring up interface: Operation not possible due to RF-kill
$

So it's running, but apparently not watching, because when I press
the button …

$ sudo rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
$

… that "unblocked" is the only change that happens. None of the three
statuses above shows any difference. So, I type …

# systemctl restart systemd-networkd.service
#

… and the only status above that changes is:

$ 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:47:50 CDT; 1min 53s ago
TriggeredBy: ● systemd-networkd.socket
Docs: man:systemd-networkd.service(8)
Main PID: 2414 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 1108)
Memory: 2.6M
CPU: 123ms
CGroup: /system.slice/systemd-networkd.service
└─2414 /lib/systemd/systemd-networkd

Mar 22 14:47:50 acer systemd[1]: Starting Network Service...
Mar 22 14:47:50 acer systemd-networkd[2414]: Enumeration completed
Mar 22 14:47:50 acer systemd[1]: Started Network Service.
Mar 22 14:47:50 acer systemd-networkd[2414]: wlp2s4: Link UP
$

I thought systemd-networkd might happen to prod ifupdown into action,
but it doesn't. So I type …

# systemctl restart if...@wlp2s4.service
#

… which results in …

$ systemctl status if...@wlp2s4.service --no-pager -l
● if...@wlp2s4.service - ifup for wlp2s4
Loaded: loaded (/lib/systemd/system/ifup@.service; static)
Active: active (exited) since Tue 2022-03-22 14:49:31 CDT; 19s ago
Process: 2489 ExecStart=/bin/sh -ec ifup --allow=hotplug wlp2s4; ifquery --state wlp2s4 (code=exited, status=0/SUCCESS)
Main PID: 2489 (code=exited, status=0/SUCCESS)
Tasks: 5 (limit: 1108)
Memory: 6.5M
CPU: 311ms
CGroup: /system.slice/if...@wlp2s4.service
├─2501 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlp2s4.pid -i wlp2s4 -D nl80211,wext -C /run/wpa_supplicant
└─2514 /sbin/dhclient -4 -v -i -pf /run/dhclient.wlp2s4.pid -lf /var/lib/dhcp/dhclient.wlp2s4.leases -I -df /var/lib/dhcp/dhclient6.wlp2s4.leases wlp2s4

Mar 22 14:49:33 acer dhclient[2514]: Sending on LPF/wlp2s4/00:11:22:33:44:55
Mar 22 14:49:33 acer dhclient[2514]: Sending on Socket/fallback
Mar 22 14:49:33 acer dhclient[2514]: DHCPDISCOVER on wlp2s4 to 255.255.255.255 port 67 interval 3
Mar 22 14:49:33 acer sh[2514]: DHCPACK of 192.168.1.10 from 192.168.1.1
Mar 22 14:49:33 acer dhclient[2514]: DHCPOFFER of 192.168.1.10 from 192.168.1.1
Mar 22 14:49:33 acer dhclient[2514]: DHCPREQUEST for 192.168.1.10 on wlp2s4 to 255.255.255.255 port 67
Mar 22 14:49:33 acer dhclient[2514]: DHCPACK of 192.168.1.10 from 192.168.1.1
Mar 22 14:49:34 acer dhclient[2514]: bound to 192.168.1.10 -- renewal in 40992 seconds.
Mar 22 14:49:34 acer sh[2514]: bound to 192.168.1.10 -- renewal in 40992 seconds.
Mar 22 14:49:34 acer sh[2564]: wlp2s4=wlp2s4
$

… and these three lines are added to the end of the output from
systemctl status systemd-networkd.service …

[ … ]
Mar 22 14:49:33 acer systemd-networkd[2414]: wlp2s4: Gained carrier
Mar 22 14:49:34 acer systemd-networkd[2414]: wlp2s4: DHCPv4 address 192.168.1.10/24 via 192.168.1.1
Mar 22 14:49:35 acer systemd-networkd[2414]: wlp2s4: Gained IPv6LL
$

… which gives me networking.

FYI, the configuration files are:

$ cat /etc/network/interfaces.d/wlp2s4
allow-hotplug wlp2s4
iface wlp2s4 inet dhcp
wpa-ssid mySSID
wpa-key-mgmt WPA-PSK
wpa-psk secret
$

$ cat /etc/systemd/network/80-wireless.network
[Match]
Name=wlp2s4
[Network]
DHCP=yes
$

What have I missed? Presumably it's something to do with “Interfaces
marked "allow-hotplug" are brought up when udev detects them. This can
either be during boot if the interface is already present, or at a
later time, for example when plugging in a USB network card. Please
note that this does not have anything to do with detecting a network
cable being plugged in.” (man interfaces).

How would I make an unblocking event look like a plugging-in event
to ifupdown?

Cheers,
David.

[Stella Ashburne]

Mon cheri

> Sent: Sunday, March 20, 2022 at 2:40 AM
> From: "Brian" <ad...@cityscape.co.uk>
> To: debia...@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

[David Wright]

On Wed 23 Mar 2022 at 13:06:12 (+0100), Stella Ashburne wrote:
> From: "Brian" <ad...@cityscape.co.uk>

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

[Brian]

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 +0000 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&wpa 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.

[Brian]

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.