[SRU] networkd-dispatcher gives corrupted information
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
networkd-dispatcher (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bionic |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Groovy |
Won't Fix
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
High
|
Unassigned | ||
Impish |
Fix Released
|
High
|
Unassigned |
Bug Description
[Impact]
* Due to changes in systemd's networkctl output networkd-dispatcher 2.0 contains a bug, producing invalid keys/values inside the JSON it provides to its scripts
* e.g.: json={"A": ["ress: 119.224.106.22 (DHCP4)"], ...}
* Therefore the scripts cannot access the relevant network configuration state
[Test Plan]
* Run systemd v244+ (e.g. in a LXD container)
* Make sure you got an IP address via DHCP:
* # networkctl status eth0
● 120: eth0
Link File: /usr/lib/
Network File: /run/systemd/
HW Address: 00:16:3e:0b:d7:74 (Xensource, Inc.)
Queue Length (Tx/Rx): 1/1
Auto negotiation: no
Search Domains: lxd
Activation Policy: up
* # cat /etc/networkd-
#!/bin/bash
env > /tmp/out.log
* chmod +x /etc/networkd-
* # networkd-dispatcher --run-startup-
* cat /tmp/out.log
* Check json= ENV to verify if it contains the correct IPv4 address (without "(DHCP4)" suffix).
[Where problems could occur]
* This was broken in 2.0 and the fix changes the behavior back to what was originally intended.
* If people adopted to the broken environment variable, to somehow parse the information they need from the broken JSON, this change will most probably break their networkd-dispatcher scripts (again).
[Other Info]
* The upstream version 2.1 just fixes the parsing of current networkctl output (in addition to a few testing and documentation improvements)
* The Debian revision -2 fixes the parsing of the "(DHCP4 ...)" suffix
* The 2.0.1 -> 2.1 version bump does not contain any relevant changes other than the fix for this bug:
The comparison (https:/
* Several fixes to Gitlab CI YAML – not relevant
* Increased logging in tests/ – not relevant
* Documentation of already existing features (README & manpage) – not relevant
* Update of copyright year – not relevant
* Update tox.ini & Gitlab CI for py38 test environment – not relevant
* fix get_networkctl_
=== Original description ===
I just reinstalled my RPI3 router from Eoan to Focal but a lot of things about networkd broke. I'm not sure whether they are related or not.
The first thing I noticed was, that I did not get my upstream DNS servers. I use a dispatcher script to extract the information from the json environment variable when my uplink becomes routable. Using a test script to dump the environment I found this:
IP6_ADDRS=
PWD=/
json={"A": ["ress: 119.224.106.22 (DHCP4)"], "Administrative
AdministrativeS
IFACE=wan
LANG=en_NZ.UTF-8
INVOCATION_
IP_ADDRS=
ESSID=
ADDR=
NOTIFY_
SHLVL=1
STATE=routable
JOURNAL_
OperationalStat
PATH=/usr/
networkd_
Note that the script worked perfectly fine on Eoan.
Also when I tried to get the dump above, I ran the following command after installing the test-script:
ip link delete wan type vlan; systemctl restart systemd-networkd
in order to force networkd to recreate and reconfigure my uplink interface. Doing this resulted in all connectivity with the router being lost (up- and downstream). After a restart, I found the following in the networkd journal indicating that networkd had in fact crashed.
Jun 19 23:59:58 tumnus systemd-
Jun 19 23:59:58 tumnus systemd-
Jun 19 23:59:58 tumnus systemd-
Jun 19 23:59:58 tumnus systemd[1]: Stopping Network Service...
Jun 19 23:59:58 tumnus systemd[1]: systemd-
Jun 19 23:59:58 tumnus systemd[1]: Stopped Network Service.
Jun 19 23:59:58 tumnus systemd[1]: Starting Network Service...
Jun 19 23:59:59 tumnus systemd-
Jun 19 23:59:59 tumnus systemd-
Jun 19 23:59:59 tumnus systemd[1]: Started Network Service.
Jun 19 23:59:59 tumnus systemd-
Jun 20 00:00:00 tumnus systemd[1]: systemd-
Jun 20 00:00:00 tumnus systemd[1]: systemd-
Jun 20 00:00:00 tumnus systemd[1]: systemd-
Jun 20 00:00:00 tumnus systemd[1]: Stopped Network Service.
Jun 20 00:00:00 tumnus systemd[1]: Starting Network Service...
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd[1]: Started Network Service.
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:00:01 tumnus systemd-
Jun 20 00:01:22 tumnus systemd[1]: Stopping Network Service...
Jun 20 00:01:22 tumnus systemd-
Jun 20 00:01:22 tumnus systemd[1]: systemd-
Jun 20 00:01:22 tumnus systemd[1]: Stopped Network Service.
-- Reboot --
However, no crash file had been generated.
The system is running systemd 245.4-4ubuntu3.1 and networkd-dispatcher 2.0.1-1.
tags: | added: rls-hh-incoming |
tags: | added: fr-878 |
tags: | removed: rls-hh-incoming |
summary: |
- networkd-dispatcher gives corrupted information + [SRU] networkd-dispatcher gives corrupted information |
description: | updated |
Changed in networkd-dispatcher (Ubuntu Hirsute): | |
status: | Fix Released → Triaged |
Changed in networkd-dispatcher (Ubuntu Hirsute): | |
status: | Triaged → In Progress |
Changed in networkd-dispatcher (Ubuntu Focal): | |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
Ok, it looks like the networkd crash & error message about enslaving a bridge to a bridge was caused by the fact that the network file for one of the bridge ports had a Match on MACAddress and came before the bridge's own network file. Therefore, on restarting networkd matched the port network file to the bridge itself (which had inherited that ports mac address) and hence tried to enslave the bridge to itself with obviously bad consequences.
It did not used to do that on Eoan, but changing the ports Match section to match on the interface's name means I can now restart networkd without it crashing (and without me loosing comms).
However, the dispatcher json is still just as mangled as before.