Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #246294 > unrolled thread

iwd + systemd-networkd + resolvconf wrinkles

Back to article view | Back to linux.debian.user

Contents

  iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-14 02:30 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Thomas Pircher <thp.debian@p5r.uk> - 2022-03-14 08:40 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-15 19:40 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Thomas Pircher <thp.debian@p5r.uk> - 2022-03-17 13:40 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
            Re: iwd + systemd-networkd + resolvconf wrinkles Nicholas Geovanis <nickgeovanis@gmail.com> - 2022-03-18 20:30 +0100
              Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-19 16:40 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 00:00 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Stefan Monnier <monnier@iro.umontreal.ca> - 2022-03-17 15:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 16:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles Stefan Monnier <monnier@iro.umontreal.ca> - 2022-03-18 13:50 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 15:50 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles Charlie <taoquester@gmail.com> - 2022-03-19 00:40 +0100
            wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-23 05:30 +0100
              Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf  wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-23 19:30 +0100
              Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf  wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-24 17:20 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 16:10 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 15:50 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles RP <reyadmin@gmail.com> - 2022-03-17 18:10 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 22:20 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-19 13:40 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Nicholas Geovanis <nickgeovanis@gmail.com> - 2022-03-19 16:40 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-21 14:20 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-19 16:40 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-19 20:00 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles Stella Ashburne <rewefie@gmx.com> - 2022-03-23 13:30 +0100
            Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-23 16:40 +0100

Page 1 of 2  [1] 2  Next page →

#246294 — iwd + systemd-networkd + resolvconf wrinkles

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.

[toc] | [next] | [standalone]

#246298

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

[toc] | [prev] | [next] | [standalone]

#246330

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.

[toc] | [prev] | [next] | [standalone]

#246381

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

[toc] | [prev] | [next] | [standalone]

#246401

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#246429

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#246466

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 (+0000), 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: <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.

[toc] | [prev] | [next] | [standalone]

#246363

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

[toc] | [prev] | [next] | [standalone]

#246382

> 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

[toc] | [prev] | [next] | [standalone]

#246386

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.

[toc] | [prev] | [next] | [standalone]

#246399

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.

[toc] | [prev] | [next] | [standalone]

#246414

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

[toc] | [prev] | [next] | [standalone]

#246398

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.

[toc] | [prev] | [next] | [standalone]

#246420

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.

[toc] | [prev] | [next] | [standalone]

#246435

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

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

[toc] | [prev] | [next] | [standalone]

#246557 — 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 +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 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 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 ifup@wlp2s4.service
# 

… which results in …

$ systemctl status ifup@wlp2s4.service --no-pager -l
● ifup@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/ifup@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.

[toc] | [prev] | [next] | [standalone]

#246573 — 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 +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.

[toc] | [prev] | [next] | [standalone]

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

[toc] | [prev] | [next] | [standalone]

#246387

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.

[toc] | [prev] | [next] | [standalone]

#246400

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.

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web