Sample Header Ad - 728x90

Unix & Linux Stack Exchange

Q&A for users of Linux, FreeBSD and other Unix-like operating systems

Latest Questions

3 votes
3 answers
4171 views
systemd networking is ignoring network configuration file on boot
I have an embedded linux system compiled with Yocto, using systemd. I have a network configuration file at ```/etc/systemd/network/20-wired.network```. The contents of that file are: [Match] Name=eth0 [Network] Address=192.168.5.40/24 Gateway=192.168.5.1 DNS=192.168.5.1 However, when I reboot my mac...
I have an embedded linux system compiled with Yocto, using systemd. I have a network configuration file at
/etc/systemd/network/20-wired.network
. The contents of that file are: [Match] Name=eth0 [Network] Address=192.168.5.40/24 Gateway=192.168.5.1 DNS=192.168.5.1 However, when I reboot my machine, the eth0 interface is successfully configured using DHCP instead of assigning the static IP address. The
a
command shows: 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether f8:dc:7a:3c:27:82 brd ff:ff:ff:ff:ff:ff inet 10.1.1.223/16 brd 10.1.255.255 scope global dynamic noprefixroute eth0 valid_lft 85898sec preferred_lft 85898sec inet6 fe80::43ec:fd39:e1c0:3c05/64 scope link noprefixroute valid_lft forever preferred_lft forever However, if I then wait 5 seconds or so after boot, and do a
restart systemd-networkd
the system will usually be configured correctly like so: 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether f8:dc:7a:3c:27:82 brd ff:ff:ff:ff:ff:ff inet 192.168.5.40/24 brd 192.168.5.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::43ec:fd39:e1c0:3c05/64 scope link noprefixroute valid_lft forever preferred_lft forever Lastly, with the right timing on the restart of the network service, I can seemingly even get this result (both the intended static address and the unwanted DHCP address): 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether f8:dc:7a:3c:27:82 brd ff:ff:ff:ff:ff:ff inet 192.168.5.40/24 brd 192.168.5.255 scope global eth0 valid_lft forever preferred_lft forever inet 10.1.1.223/16 brd 10.1.255.255 scope global dynamic noprefixroute eth0 valid_lft 86246sec preferred_lft 86246sec inet6 fe80::43ec:fd39:e1c0:3c05/64 scope link noprefixroute valid_lft forever preferred_lft forever Does anyone know what is going on here or how to debug this? Is there something obvious wrong with my configuration?
status systemd-networkd
shows the following immediately after boot (specifically after network-online.target): * systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: activating (start) since Tue 2021-07-20 12:58:52 UTC; 65ms ago TriggeredBy: * systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 282 ((networkd)) Tasks: 1 (limit: 3576) Memory: 416.0K CGroup: /system.slice/systemd-networkd.service `-282 (networkd) Some number of seconds later it looks like this: * systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2021-07-20 12:58:52 UTC; 3min 20s ago TriggeredBy: * systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 282 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 3576) Memory: 2.0M CGroup: /system.slice/systemd-networkd.service `-282 /lib/systemd/systemd-networkd So it looks like the service is still "activating" when the network-online.target services run. I'm not sure what that means, though, or if it's a problem.
Dave (91 rep)
Jul 19, 2021, 08:40 PM • Last activity: Aug 1, 2025, 03:12 AM
0 votes
1 answers
2484 views
How to make WiFi reduced transmit power level persist across reboots?
**TL;DR** I have reduced the transmit power of a WiFi device and I would like to make this change permanent, so it does not revert after a reboot. **Details** I have joined two Raspberry Pi 4 devices to an existing WiFi network, and I have discovered that by default they transmit at 31 dBm, which is...
**TL;DR** I have reduced the transmit power of a WiFi device and I would like to make this change permanent, so it does not revert after a reboot. **Details** I have joined two Raspberry Pi 4 devices to an existing WiFi network, and I have discovered that by default they transmit at 31 dBm, which is quite high. I was getting a lot of latency, in that it would work fine for 10 seconds and then pretty much stop for 5 seconds, then repeat. I discovered that if I lower the transmit power on both devices to only 10 dBm then the latency dramatically improves. I did this by running the command iw wlan0 set txpower limit 1000. I would like to make this setting persistent across reboots, however I can't see anything in systemd-networkd or wpa_supplicant that controls transmit power. Is there a way to set this (e.g. in systemd's .network or .link file for the WiFi connection)? Failing that, what would be the best way to do this? I am guessing a udev rule would be better than a systemd service as it would run only when the device is available however any advice would be appreciated.
Malvineous (7395 rep)
Feb 19, 2022, 07:08 AM • Last activity: Jul 29, 2025, 08:02 AM
5 votes
2 answers
2482 views
Execute a script on ethernet connection/disconnection with systemd
I have an embedded device that will connect with [`systemd-networkd`][1] to a DHCP server if connected to the local network and will fall back to being a DHCP server if not. I didn't implement it yet but plan using the answer described [here][2]. This answer points to use a script that will be start...
I have an embedded device that will connect with systemd-networkd to a DHCP server if connected to the local network and will fall back to being a DHCP server if not. I didn't implement it yet but plan using the answer described here . This answer points to use a script that will be started on boot. I was wondering what if the user unplugs the network cable and connects it to a PC at runtime, he'd need to restart the board for the script to start. So the question is: is there a way to start a script when there's an interface change with systemd? I tried using [networkd-dispatcher](https://gitlab.com/craftyguy/networkd-dispatcher) without success. I tried restarting the systemd-networkd service, unplug the Ethernet cable, but the script I wrote located in /usr/lib/networkd-dispatcher is not executed.
David Bensoussan (151 rep)
May 31, 2019, 04:04 PM • Last activity: Jul 23, 2025, 04:03 PM
3 votes
2 answers
3320 views
Enabling networking in a systemd-nspawn container
I'm trying to setup container that has access to the internet but have been unsuccessful so far. # sudo systemd-nspawn -nb -M debian-tree # systemctl enable --now systemd-networkd systemd-resolved # ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # ip link 1: lo: mtu 65536 qdisc noqueue sta...
I'm trying to setup container that has access to the internet but have been unsuccessful so far. # sudo systemd-nspawn -nb -M debian-tree # systemctl enable --now systemd-networkd systemd-resolved # ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: host0@if8: mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 42:ca:d5:8c:af:60 brd ff:ff:ff:ff:ff:ff link-netnsid 0 # ping google.com ping: google.com: Temporary failure in name resolution On the host # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: wlp1s0: mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 7c:7a:91:ae:7d:47 brd ff:ff:ff:ff:ff:ff 8: ve-debian-tree@if2: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 92:f7:e1:4b:c6:6f brd ff:ff:ff:ff:ff:ff link-netnsid 0 Any ideas why it's not working?
Ava (143 rep)
Jul 27, 2017, 11:15 PM • Last activity: Jul 13, 2025, 11:06 PM
3 votes
1 answers
1887 views
systemd-resolved change dns cname records
I have a PC with Arch Linux (4.7.2-1-ARCH) on it. The PC uses DHCP to get its IP, but uses a different DNS Server that i configured via systemd-resolved. When I use the dig command with a domain the has a CNAME record, the associated A record is missing. If I use dig with the server manualy configur...
I have a PC with Arch Linux (4.7.2-1-ARCH) on it. The PC uses DHCP to get its IP, but uses a different DNS Server that i configured via systemd-resolved. When I use the dig command with a domain the has a CNAME record, the associated A record is missing. If I use dig with the server manualy configured the A record is there. Any ideas why the systemd-resolved changes the dns records? If you need any additional infos let me know. Here is my network (systemd-networkd) configuration [Match] Name=ens18 [Network] DNS=10.0.0.18 DHCP=ipv4 [DHCPv4] UseHostname=false UseDNS=false resolv.conf: # This is a static resolv.conf file for connecting local clients to # systemd-resolved via its DNS stub listener on 127.0.0.53. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 dig api.pushbullet.com: ; > DiG 9.10.4-P2 > api.pushbullet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER> DiG 9.10.4-P2 > api.pushbullet.com @10.0.0.18 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33081 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;api.pushbullet.com. IN A ;; ANSWER SECTION: api.pushbullet.com. 184 IN CNAME ghs-svc-https-c573.ghs-ssl.googlehosted.com. ghs-svc-https-c573.ghs-ssl.googlehosted.com. 282 IN A 72.14.247.65 ;; AUTHORITY SECTION: . 509182 IN NS j.root-servers.net. . 509182 IN NS d.root-servers.net. . 509182 IN NS a.root-servers.net. . 509182 IN NS l.root-servers.net. . 509182 IN NS g.root-servers.net. . 509182 IN NS b.root-servers.net. . 509182 IN NS m.root-servers.net. . 509182 IN NS i.root-servers.net. . 509182 IN NS f.root-servers.net. . 509182 IN NS h.root-servers.net. . 509182 IN NS e.root-servers.net. . 509182 IN NS k.root-servers.net. . 509182 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 10.0.0.18#53(10.0.0.18) ;; WHEN: Son Sep 11 01:17:59 CEST 2016 ;; MSG SIZE rcvd: 328
Stoffl (131 rep)
Sep 10, 2016, 11:44 PM • Last activity: Jul 6, 2025, 02:01 PM
0 votes
1 answers
4324 views
Static IP and netplan stop working a couple days after fresh install Ubuntu Server 18.04 LTS
Having some major issues with networking on Ubuntu 18.04 LTS. Fresh install. I set a static IP during install which worked for a couple days and remained set after multiple reboots. Now the interface shows no IP. It seems when I set that IP it did generate a netplan that appears correct however netp...
Having some major issues with networking on Ubuntu 18.04 LTS. Fresh install. I set a static IP during install which worked for a couple days and remained set after multiple reboots. Now the interface shows no IP. It seems when I set that IP it did generate a netplan that appears correct however netplan apply does nothing. This happened to me previously as well on the previous install. I had been messing with some DNS stuff so I figured I'd just reimage the machine and not touch any of the network utilities this time and I still am having the issue. The issue occurs about a day and a half after install seemingly randomly. Was not using the machine when the issue began and the only thing I have done so far on this install is set up a couple docker containers with samba and SFTP. Contents of my 50-cloud-init.yaml
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s25:
            dhcp4: no
            addresses: [192.168.0.32/24]
            gateway4: 192.168.0.1
            nameservers:
                addresses: [1.1.1.1,8.8.8.8]
Terminal output from netplan --debug apply
** (generate:2227): DEBUG: 23:11:19.520: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:2227): DEBUG: 23:11:19.520: starting new processing pass
** (generate:2227): DEBUG: 23:11:19.520: enp0s25: setting default backend to 1
** (generate:2227): DEBUG: 23:11:19.520: Generating output files..
** (generate:2227): DEBUG: 23:11:19.520: NetworkManager: definition enp0s25 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:enp0s25 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    enp0s25:
      addresses:
      - 192.168.0.32/24
      dhcp4: false
      gateway4: 192.168.0.1
      nameservers:
        addresses:
        - 1.1.1.1
        - 8.8.8.8
  vlans: {}
  wifis: {}

DEBUG:Skipping non-physical interface: lo
DEBUG:Skipping non-physical interface: docker0
DEBUG:Skipping non-physical interface: br-98e8ea9c70cb
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp0s25
DEBUG:netplan triggering .link rules for docker0
DEBUG:netplan triggering .link rules for br-98e8ea9c70cb
My ifconfig
br-98e8ea9c70cb: flags=4099  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        ether 02:42:51:a6:a3:66  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:d5:d6:46:8e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s25: flags=4099  mtu 1500
        ether 00:24:7e:00:e0:30  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xfc500000-fc520000  

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 7926  bytes 592108 (592.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7926  bytes 592108 (592.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
CNorlander (101 rep)
Feb 14, 2019, 10:23 PM • Last activity: Jul 2, 2025, 03:04 PM
0 votes
2 answers
557 views
systemd-networkd bridge does not work with VLAN
I am trying to configure one bridge per VLAN (without VLAN filtering) with ```systemd-networkd``` for easy configuration of libvirt VMs on Debian 12. This does work as expected without VLAN and it does work with VLAN with some manual help (`ip link set master ...`). The problem symptom is that ```sy...
I am trying to configure one bridge per VLAN (without VLAN filtering) with
-networkd
for easy configuration of libvirt VMs on Debian 12. This does work as expected without VLAN and it does work with VLAN with some manual help (ip link set master ...). The problem symptom is that
-networkd
does create the bridge and VLAN interfaces but does not connect them:
2: onbunten:  mtu 1500 qdisc mq master brlan state UP group default qlen 1000
    link/ether 04:92:26:b7:a9:9f brd ff:ff:ff:ff:ff:ff
4: brlan:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c6:50:f5:f2:22:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.222/24 brd 192.168.2.255 scope global brlan
       valid_lft forever preferred_lft forever
5: brvlan2:  mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 46:ba:f7:a8:3d:d7 brd ff:ff:ff:ff:ff:ff
6: brvlan3:  mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 26:96:9b:cc:69:af brd ff:ff:ff:ff:ff:ff
7: onbunten.4@onbunten:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 04:92:26:b7:a9:9f brd ff:ff:ff:ff:ff:ff
8: onbunten.2@onbunten:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 04:92:26:b7:a9:9f brd ff:ff:ff:ff:ff:ff
9: onbunten3@onbunten:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 04:92:26:b7:a9:9f brd ff:ff:ff:ff:ff:ff
The
.2
/
pattern difference is intentional; for testing whether that made any difference. I have found descriptions on the Internet which seem to state that what I did is the solution. I also found the statement > This configuration is deprecated and no longer supported on this site (the answer ); unfortunately without a clear explanation what exactly is supposed to be deprecated (I did not find any such hints in the Systemd man pages). I have been running systemd-networkd in debug mode (SYSTEMD_LOG_LEVEL=debug) but among the 500 lines of logging I do not notice any which are related to the VLAN and bridge interfaces simultaneously. No error messages. # the config files ## this is what does work
==> 31-brlan.netdev  32-brvlan2.netdev  33-brvlan3.netdev  41-onbunten-vlans.network  61-brlan-onbunten.network  71-brlan.network  62-brvlan2-onbunten2.network  63-brvlan3-onbunten3.network  72-brvlan2.network  73-brvlan3.network <==
[Match]
Name=brvlan3

[Network]
DHCP=no
LinkLocalAddressing=no
Gateway=192.168.116.1
# NTP=
ConfigureWithoutCarrier=yes
IgnoreCarrierLoss=yes

[Address]
Address=192.168.116.222/24
DuplicateAddressDetection=ipv4
Scope=global
Hauke Laging (93688 rep)
Dec 26, 2023, 07:19 PM • Last activity: Jun 23, 2025, 07:38 PM
0 votes
0 answers
42 views
How to debug why systemd-networkd ignoring netdev file for sit tunnel
I would like to use systemd-networkd to set up an IPv6 tunnel to tunnelbroker.net. I have created two files in `/etc/systemd/network`, called `ip6tun.netdev` and `ip6tun.network`, respectively. My `ip6tun.network` file works correctly, in the sense that if I manually create the tunnel with the follo...
I would like to use systemd-networkd to set up an IPv6 tunnel to tunnelbroker.net. I have created two files in /etc/systemd/network, called ip6tun.netdev and ip6tun.network, respectively. My ip6tun.network file works correctly, in the sense that if I manually create the tunnel with the following command, systemd-networkd automatically assigns the correct IP address to the new ip6tun network interface:
ip tunnel add ip6tun mode sit remote $REMOTEIP local $MYIP ttl 255
Unfortunately, it seems to ignore my netdev file and not create the interface on its own. Here's my netdev file (where I've changed the raw IP addresses to fake ones and added a comment for privacy):
[Match]
 
[NetDev]
Name=ip6tun
Kind=sit
#MTUBytes=1480
 
[Tunnel]
Local=1.2.3.4     # actual file has real address
Remote=5.6.7.8    # actual file has real address
TTL=255
Note that other than the IP addresses, this netdev file is identical to one I have working at a different site. When I stop the unit file and manually run SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd, there are only two mentions of ip6tun:
/etc/systemd/network/ip6tun.netdev: Successfully loaded.
/usr/lib/systemd/network/80-6rd-tunnel.network: Successfully loaded.
Failed to read $container of PID 1, ignoring: Permission denied
Found container virtualization none.
No virtualization found in DMI vendor table.
Unable to read /sys/firmware/dmi/entries/0-0/raw, using the virtualization information found in DMI vendor table, ignoring: Permission denied
...
/etc/systemd/network/eth0.network: Successfully loaded.
/etc/systemd/network/eth1.network: Successfully loaded.
/etc/systemd/network/ip6tun.network: Successfully loaded.
Loaded.
When I run systemd-networkd from the .service unit file, with the following commands, I also don't see any error messages in the system log, other than the fact that ip6tun.netdev was successfully loaded:
systemctl set-environment SYSTEMD_LOG_LEVEL=debug
systemctl restart systemd-networkd
I guess one question I have is what am I doing wrong and how to fix it. But a bigger question is how to go about debugging these kinds of problems. I find that I often end up in situations where I just want the equivalent of a simple command to be run, yet I have no idea why the systemd equivalent is not working and I end up completely stumped as to how to proceed. I suppose in this case I could create a service file to run the ip tunnel add command, but then what is the point of .netdev files?
user3188445 (5539 rep)
Jun 18, 2025, 06:18 PM
0 votes
0 answers
20 views
Can systemd-networkd make a DCHPv4 request on qmi_wwan device?
I have this: ``` # cat 80-wwan0.network [Match] Name=wwan0 [Network] DHCP=ipv4 KeepConfiguration=dhcp IgnoreCarrierLoss=yes ``` udhcpc from busybox has no issues: ``` # udhcpc -i wwan0 udhcpc: started, v1.35.0 udhcpc: broadcasting discover udhcpc: broadcasting select for 10.189.97.135, server 10.189...
I have this:
# cat 80-wwan0.network 
[Match]
Name=wwan0

[Network]
DHCP=ipv4
KeepConfiguration=dhcp
IgnoreCarrierLoss=yes
udhcpc from busybox has no issues:
# udhcpc -i wwan0
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting select for 10.189.97.135, server 10.189.97.136
udhcpc: lease of 10.189.97.135 obtained from 10.189.97.136, lease time 7200
` systemd-networkd:
# networkctl reconfigure wwan0
Result:
Jun 11 19:18:03 SYSTEM systemd-networkd: wwan0: Reconfiguring with /etc/systemd/network/80-wwan0.network.
Jun 11 19:18:04 SYSTEM systemd-networkd: wwan0: DHCPv6 lease lost
And udhcpc can still get the lease:
udhcpc -i wwan0
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting select for 10.189.97.135, server 10.189.97.136
udhcpc: lease of 10.189.97.135 obtained from 10.189.97.136, lease time 7200
John Klug (1 rep)
Jun 12, 2025, 12:23 AM
69 votes
3 answers
57056 views
How exactly are NetworkManager, networkd, netplan, ifupdown2, and iproute2 interacting?
I am learning about Linux networking on my Kubuntu 18.04 workstation, and I see there that both `NetworkManager` and `networkd-dispatcher` are running: oleg@eclectic:~$ sudo ps -ef | grep -i net root 56 2 0 Oct11 ? 00:00:00 [netns] root 1097 1 0 Oct11 ? 00:00:02 /usr/sbin/NetworkManager --no-daemon...
I am learning about Linux networking on my Kubuntu 18.04 workstation, and I see there that both NetworkManager and networkd-dispatcher are running: oleg@eclectic:~$ sudo ps -ef | grep -i net root 56 2 0 Oct11 ? 00:00:00 [netns] root 1097 1 0 Oct11 ? 00:00:02 /usr/sbin/NetworkManager --no-daemon root 1098 1 0 Oct11 ? 00:00:00 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers root 1250 1 0 Oct11 ? 00:00:02 /usr/sbin/inetd root 1593 1097 0 Oct11 ? 00:00:00 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper... NetworkManager seems to be configured to handle "everything" by netplan: oleg@eclectic:~$ cat /etc/netplan/01-network-manager-all.yaml # Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager I believe that netplan would hand everything off to networkd if NetworkManager was not installed. There are also a bunch of files in /etc/network/, and I am not sure what is handling those. A lot of packages seem to use this directory: oleg@eclectic:~$ dpkg -S /etc/network avahi-daemon, ifupdown2, wpasupplicant, openvpn, postfix, netbase, avahi-autoipd, wireless-tools, clamav-freshclam: /etc/network My initial thoughts after some Googling are that NetworkManager and networkd are both running, but netplan generates configuration such that only one is actually doing something. But I do not know how I would verify this, figure out the chain of operations, or configure it to suit my nefarious plans for dummy0. **Question:** How exactly are NetworkManager, networkd, and netplan working together? In other words, as the computer boots up, which processes hand what of to what other processes? How do tools from packages like net-tools, ifupdown2, and iproute2 and directories like /etc/network/ fit into all this? And finally, how can I figure this out myself and learn the details using the command line? **Update:** I am not looking for a high-level overview. Rather, I want to know how these components are interacting, conflicting, or avoiding conflict on the kernel level or similar.
Oleg Pryadko (2500 rep)
Oct 12, 2018, 06:02 PM • Last activity: Jun 9, 2025, 02:11 PM
2 votes
1 answers
3884 views
systemd-networkd-wait-online.service keeps failing
I am having a strange problem trying to get network working on Linux using systemd. My network `eth0` is connected to a corporate network with a DHCP server: ``` # more /etc/systemd/network/main.network #Main connection to the outside world [Match] Name=eth0 [Network] DHCP=yes IPForward=yes ``` ```...
I am having a strange problem trying to get network working on Linux using systemd. My network eth0 is connected to a corporate network with a DHCP server:
# more /etc/systemd/network/main.network

#Main connection to the outside world
[Match]
Name=eth0
[Network]
DHCP=yes 
IPForward=yes
# networkctl status eth0

2: eth0
           Link File: n/a
        Network File: /etc/systemd/network/main.network
                Type: ether
               State: routable (configured)
          HW Address: 00:03:2d:32:85:3a (IBASE Technology, Inc.)
                 MTU: 1500
             Address: 10.0.7.134
                      fe80::203:2dff:fe32:853a
             Gateway: 10.0.7.1
                 DNS: 10.0.7.10
However, wait-online service fails:
# /lib/systemd/systemd-networkd-wait-online --interface eth0 --timeout=10

ignoring: sit0
Event loop failed: Connection timed out
The system had acquired a valid IP address on eth0 so I don't understand why it would not be online. I have another interface in the system, eth1, that is not plugged in.
Alex Gdalevich (121 rep)
Nov 1, 2016, 03:09 PM • Last activity: May 28, 2025, 09:04 AM
5 votes
1 answers
231 views
How do systemd-nspawn and systemd-networkd implement NAT?
I'm trying to understand how systemd-nspawn manages internet access and port-forwarding for containers. I set up an nspawn container with `--network-veth` and a port forwarding with `--port=80`. Both host and container run systemd-networkd. Everything works perfectly: the container can access the in...
I'm trying to understand how systemd-nspawn manages internet access and port-forwarding for containers. I set up an nspawn container with --network-veth and a port forwarding with --port=80. Both host and container run systemd-networkd. Everything works perfectly: the container can access the internet, and incoming traffic to port 80 gets forwarded to the container. I'd like to understand and inspect how systemd manages this. I was (naively?) expecting to find related rules in iptables, but if I run iptables -t ... -S all tables look empty, both in the host and the container. I also ran the same command with nsenter to enter the network namespace of the veth, but I still see no rules. So, does systemd not use Netfilter for NAT/Masquerading? If not, what does it use?
Luca De Feo (155 rep)
Apr 23, 2025, 02:18 PM • Last activity: Apr 23, 2025, 04:21 PM
0 votes
0 answers
610 views
Sharing Ethernet connection with Wifi and USB ethernet using systemd-networkd
I am running Raspbian 11 on a Raspberry Pi 4 and have connected a USB Ethernet NIC. My goal is to allow clients to connect via Wi-Fi (wlan0) or the USB Ethernet adapter (eth1), then have the Raspberry Pi route all traffic through the primary Ethernet connection (eth0). This setup must still function...
I am running Raspbian 11 on a Raspberry Pi 4 and have connected a USB Ethernet NIC. My goal is to allow clients to connect via Wi-Fi (wlan0) or the USB Ethernet adapter (eth1), then have the Raspberry Pi route all traffic through the primary Ethernet connection (eth0). This setup must still function when eth0 is disconnected (though obviously without internet access). **Problem**: I have configured all interfaces (wlan0, eth1, and eth0), but traffic from wlan0 and eth1 is not being routed through eth0 to the internet.. Here is how I have configured systemd-networkd: /etc/systemd/network/09-default.network: [Match] Name=eth0 [Link] RequiredForOnline=no [Network] DHCP=ipv4 [Bridge] Priority=0 [DHCPv4] ClientIdentifier=mac /etc/systemd/network/10-wlan0.network: [Match] Name=wlan0 Type=wlan [Network] DHCP=no Address=192.168.8.1/24 DHCPServer=yes IPMasquerade=yes [DHCPServer] PoolOffset=10 PoolSize=100 /etc/systemd/network/11-eth1.network: [Match] Name=eth1 [Network] DHCP=no Address=192.168.10.1/24 DHCPServer=yes IPForward=yes IPMasquerade=yes [DHCPServer] PoolOffset=10 PoolSize=100
Jim Cortez (101 rep)
Jun 9, 2023, 11:14 PM • Last activity: Apr 3, 2025, 09:57 AM
3 votes
1 answers
522 views
How do I give my container a static ip address (systemd-nspawn)
My container changes its ip address extremely often, almost every boot. I tried giving it a static ip address so my script knows how to ssh into it but nothing I did seemed to work. So I tried looking into the host side. No luck either. After doing the below (and rebooting my system). I tried bootin...
My container changes its ip address extremely often, almost every boot. I tried giving it a static ip address so my script knows how to ssh into it but nothing I did seemed to work. So I tried looking into the host side. No luck either. After doing the below (and rebooting my system). I tried booting with -b -D path -n. When I do I get 0 connectivity. systemctl list-units --type=service show systemd-networkd.service as loaded active running. I'm not sure what could be wrong. The container is alpine and the host is arch cp /usr/lib/systemd/network/80-container-host0.network /etc/systemd/network/
Andrew Benor (31 rep)
Oct 8, 2022, 12:26 AM • Last activity: Mar 5, 2025, 08:16 PM
3 votes
1 answers
158 views
eduroam works on systemd-networkd but not on NetworkManager
After two years and countless hours of trying to fix this issue, I was finally able to connect to eduroam (Enterprise WPA) from Arch. I was able to do this by ignoring NetworkManager entirely and using wpa_supplicant explicitly. Today I have learned of the existence of systemd-networkd and it allows...
After two years and countless hours of trying to fix this issue, I was finally able to connect to eduroam (Enterprise WPA) from Arch. I was able to do this by ignoring NetworkManager entirely and using wpa_supplicant explicitly. Today I have learned of the existence of systemd-networkd and it allows me to connect to the internet. As I use NetworkManager on other machines for home WiFi connections, VPNs, etc., I would like to also get eduroam working with my original NetworkManager setup. Here is my current (working) setup:
> cat /etc/wpa_supplicant/wpa_supplicant-wlan0.conf`
network={
        ssid="eduroam"
        key_mgmt=WPA-EAP
        eap=PEAP
        identity="username@domain"
        password="********"
        phase2="auth=MSCHAPV2"
}

> systemctl stop NetworkManager.service 
> systemctl start wpa_supplicant@wlan0.service systemd-networkd.service systemd-resolved.service dhcpcd.service
I have the (to my eyes) equivalent NetworkManager config, which doesn't work:
> cat /etc/NetworkManager/system-connections/eduroam.nmconnection
[connection]
id=eduroam
uuid=95580564-0352-438d-9804-364636618a28
type=wifi

[wifi]
mode=infrastructure
ssid=eduroam

[wifi-security]
key-mgmt=wpa-eap

[802-1x]
eap=peap;
identity=username@domain
password=********
phase2-auth=mschapv2

[ipv4]
method=auto

[ipv6]
method=auto

[proxy]

> nmcli con up eduroam
Error: Connection activation failed: The Wi-Fi network could not be found
Hint: use 'journalctl -xe NM_CONNECTION=95580564-0352-438d-9804-364636618a28 + NM_DEVICE=wlan0' to get more details.

> journalctl -xe NM_CONNECTION=95580564-0352-438d-9804-364636618a28 + NM_DEVICE=wlan0
Jun 18 16:15:03 kim-xps13-9343 NetworkManager:   [1718720103.7090] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 18 16:15:08 kim-xps13-9343 NetworkManager:   [1718720108.2210] device (wlan0): supplicant interface state: scanning -> disconnected
Jun 18 16:15:18 kim-xps13-9343 NetworkManager:   [1718720118.2758] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 18 16:15:22 kim-xps13-9343 NetworkManager:   [1718720122.7869] device (wlan0): supplicant interface state: scanning -> disconnected
Jun 18 16:15:25 kim-xps13-9343 NetworkManager:   [1718720125.1830] device (wlan0): Activation: (wifi) association took too long, failing activation
Jun 18 16:15:25 kim-xps13-9343 NetworkManager:   [1718720125.1831] device (wlan0): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed')
Jun 18 16:15:25 kim-xps13-9343 NetworkManager:   [1718720125.1843] device (wlan0): Activation: failed for connection 'eduroam'
Jun 18 16:15:25 kim-xps13-9343 NetworkManager:   [1718720125.1845] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jun 18 16:15:44 kim-xps13-9343 NetworkManager:   [1718720144.8036] device (wlan0): supplicant interface state: disconnected -> inactive
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7364] device (wlan0): Activation: starting connection 'eduroam' (95580564-0352-438d-9804-364636618a28)
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7364] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7369] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7372] device (wlan0): Activation: (wifi) access point 'eduroam' has security, but secrets are required.
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7372] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7382] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7385] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7387] device (wlan0): Activation: (wifi) connection 'eduroam' has security, and secrets exist.  No new secrets needed.
Jun 18 16:17:03 kim-xps13-9343 NetworkManager:   [1718720223.7461] device (wlan0): supplicant interface state: inactive -> disconnected
Jun 18 16:17:13 kim-xps13-9343 NetworkManager:   [1718720233.7945] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 18 16:17:18 kim-xps13-9343 NetworkManager:   [1718720238.3069] device (wlan0): supplicant interface state: scanning -> disconnected
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2291] device (wlan0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2300] device (wlan0): disconnecting for new activation request.
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2312] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2323] device (wlan0): Activation: starting connection 'eduroam' (95580564-0352-438d-9804-364636618a28)
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2330] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2335] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2338] device (wlan0): Activation: (wifi) access point 'eduroam' has security, but secrets are required.
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2338] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2350] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2353] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 18 16:17:23 kim-xps13-9343 NetworkManager:   [1718720243.2355] device (wlan0): Activation: (wifi) connection 'eduroam' has security, and secrets exist.  No new secrets needed.
What could be happening here?
Post Self (323 rep)
Jan 6, 2025, 12:47 PM • Last activity: Jan 17, 2025, 04:40 PM
1 votes
2 answers
612 views
how can I prevent networkd from raising interface while still allowing dhcp configuration
I am trying to use systemd-networkd to configure my network. I would like to have a dhcp setting but I must keep the interface from being up. The step scenario would be - Machine boot up - Network interfaces are down - Manual raising of net-interface - Requests to dhcp are made. I have not beeen abl...
I am trying to use systemd-networkd to configure my network. I would like to have a dhcp setting but I must keep the interface from being up. The step scenario would be - Machine boot up - Network interfaces are down - Manual raising of net-interface - Requests to dhcp are made. I have not beeen able to keep interfaces down and dhcp config. I also tried having no config and managing request using dhclient but having multiple interfaces gives me a weird routing-table(this in itself could be another question in the future). For a bit more information. I have a regular RJ45 network port and several USB modems that I would like to plugin without automatic-connect.
user3817810 (11 rep)
May 30, 2022, 04:23 PM • Last activity: Jan 16, 2025, 03:11 PM
8 votes
3 answers
8273 views
What are link "scopes" in systemd-resolved?
While trying to fix a DNS issue with NetworkManager's ModemManager on Ubuntu, I came across this difference in the output of `systemd-resolve --status` when connected. (`ping` ip works, manually editing `/etc/resolv.conf` fixes the problem, and setting FallbackDNS also fixes the problem, but all wit...
While trying to fix a DNS issue with NetworkManager's ModemManager on Ubuntu, I came across this difference in the output of systemd-resolve --status when connected. (ping ip works, manually editing /etc/resolv.conf fixes the problem, and setting FallbackDNS also fixes the problem, but all with side-effects. **Working installation - PPP modem** (Ubuntu 17.10) Link 3 (wwp0s20u6) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 198.142.0.51 211.29.132.12 **Broken installation - PPP modem** (Same hardware - Lubuntu 17.04) Link 2 (wwp0s20u6) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no These are both versions of Ubuntu and identical hardware. The configs of the network connections in /etc/NetworkManager/system-connections are also identical. On links with DHCP like ethernet and Wifi adapters, the DNS scope is added to the link and DNS works correctly on both machines. e.g. **Broken installation - WiFi adapter working** Link 3 (wlan0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.0.1 So, I speculate that it's not a problem with systemd-resolved itself, but with something that tells systemd-resolved it should be looking for DNS. ***What are systemd link "Scopes"?*** ***Why would one machine assign the "DNS" scope and the other not?***
tudor -Reinstate Monica- (545 rep)
Nov 16, 2017, 03:39 AM • Last activity: Dec 9, 2024, 10:30 PM
1 votes
1 answers
316 views
Getting systemd-networkd to honor [DHCPv4] FallbackLeaseLifetimeSec option
*Related to [this question][1]* How do you get `systemd-networkd` to honor the `[DHCPv4]` setting `FallbackLeaseLifetimeSec=forever`? (Or more probably, what am I doing wrong that is preventing this?) When it receives a reply with no DHCP lease, it logs: ``` enp0s1: DHCPv4 client: received lease lac...
*Related to this question * How do you get systemd-networkd to honor the [DHCPv4] setting FallbackLeaseLifetimeSec=forever? (Or more probably, what am I doing wrong that is preventing this?) When it receives a reply with no DHCP lease, it logs:
enp0s1: DHCPv4 client: received lease lacks address, server address or lease lifetime, ignoring
## Background ## We have a prospective customer with a requirement that our device can operate in a BOOTP (i.e. non-DHCP) environment. Specifically, we must not require DHCP Option 51 (Lease Time) to be present, and must treat replies as permanent IP assignments. We use systemd-networkd for everything else, so ideally we'd like to use its built-in DHCP client for this as well. The primary issue is that systemd-networkd is rejecting BOOTP replies that do not contain DHCP Option 51 (IP Address Lease Time). It appears that the entire purpose of FallbackLeaseLifetimeSec=forever is to bypass this constraint. However, whether we set it or not, we get the same log message (above), and the systemd does not configure the interface. Details/what I've tried ----------------------- - networkctl --version reports systemd 252. The doc say this option was added in 246. - We are running Debian 12 (Bookworm) as a testbed client, w/ a 6.1.0 kernel. - We are running the Debian bootpd package on a separate device, w/ the same Debian & Linux - Probably irrelevant, but the server is using /etc/network/interfaces and ifup/ifdown for network config. - I've captured the replies via tcpdump and verified the following: - They contain yiaddr, aka Your (client) IP Address - They contain siaddr, aka Server Ip Address - They do also contain option 54 (DHCP Server Identifier) - I've captured replies from a normal DHCP server, and compared as well. The only substantive differences I can see are: - The expected IP Address Lease Time is present - The options are in a different order (53,54,51,1,3,6,42,255 vs 1,3,53,54,6,12,255) - Our network config file is in /etc/systemd/network/20-enp0s1.network - We have no other network config files, except /etc/systemd/networkd.conf which is untouched, and effectively blank (it has only comments and some empty sections) - I have verified that our config file, and the FallbackLeaseLifetimeSec option in particular, are being parsed as follows: - I set the options's value to garbage, and restarted systemd-networkd. - journalctl reports Invalid LeaseLifetime= value, ignoring: garbage. - When I switch it back to forever, journalctl doesn't mention it - I found the error message in the source code, and it's clear that it is quiet if it finds an acceptable value. - Here is 20-enp0s1.network:
[Match]
Name=enp0s1

[Network]
DHCP=ipv4

[DHCPv4]
FallbackLeaseLifetimeSec=forever

ClientIdentifier=mac  

# Padding b/c bootpd rejects packets that it thinks are too short
SendOption=254:string:"UUUUUUUUUUUUUUUUUUUUUUUUUUU"
Avram (183 rep)
Nov 13, 2024, 12:00 AM • Last activity: Nov 22, 2024, 03:56 PM
0 votes
0 answers
225 views
How to add usb0 (gadget ethernet interface) to a network bridge using systemd-networkd
I have a working systemd network bridge br0 that I setup by creating the following two files: ``` # cat /etc/systemd/network/br0.netdev [NetDev] Name=br0 Kind=bridge # cat /etc/systemd/network/br0.network [Match] Name=br0 [Network] Address=192.168.0.1/24 ``` I then added eth1 (a usb-eth adapter) as...
I have a working systemd network bridge br0 that I setup by creating the following two files:
# cat /etc/systemd/network/br0.netdev
[NetDev]
Name=br0
Kind=bridge

# cat /etc/systemd/network/br0.network
[Match]
Name=br0
[Network]
Address=192.168.0.1/24
I then added eth1 (a usb-eth adapter) as well as a dummy interface to the bridge like so:
# cat /etc/systemd/network/dummy0.network
[Match]
Name=dummy0
[Network]
Bridge=br0

# cat /etc/systemd/network/eth1.network
[Match]
Name=eth1
[Network]
Bridge=br0
This works well for what I need; it allows me to use the address 192.168.0.1 even if the usb-eth adapter is not plugged in and eth1 is not in the interface list. I added a USB gadget ethernet connection by calling modprobe g_ether which creates the interface usb0, that automatically comes up with address 192.168.11.1 and provides a DHCP address to the device connected to it over USB. I tried to add usb0 to the bridge like dummy0 and eth1, by creating this file:
# cat /etc/systemd/network/usb0.network
[Match]
Name=usb0
[Network]
Bridge=br0
But it still comes up with its default address 192.168.11.1 and still serves a DHCP address to its remote connection. Calling bridge link I still only see dummy0 and eth1. Any way to disable this default behavior so I can add it to my bridge?
fourstar (1 rep)
Nov 4, 2024, 02:09 PM • Last activity: Nov 4, 2024, 02:15 PM
1 votes
1 answers
36 views
How to: local traffic through ibss network, www through a managed network
I have several local computers in a simple home setup, the interfaces all configured with systemd-networkd (systemd version 252), all running in debian bookworm (12.7). Each computer has a wifi dongle to connect to the local network, and either built-in wifi or ethernet to connect to a dsl router (w...
I have several local computers in a simple home setup, the interfaces all configured with systemd-networkd (systemd version 252), all running in debian bookworm (12.7). Each computer has a wifi dongle to connect to the local network, and either built-in wifi or ethernet to connect to a dsl router (which is the access point for the non-local wifi network). I wish to have the local network use ipv6 link-local addressing exclusively and *not go through the dsl router*. Setting up the non-local network is easy and uses the systemd dhcp facility and wpa-supplicant-nl80211@*interface*.service. Can anyone suggest how to write the *local*.network file? Such that one local machine talking to the next is a simple point-to-point connection over the ibss network.
Roberta (13 rep)
Oct 21, 2024, 10:48 PM • Last activity: Oct 22, 2024, 06:05 AM
Showing page 1 of 20 total questions