Use systemd-resolve with NetworkManager, use netplan for bridging, Fix DEPRECATION WARNINGs #4093
Conversation
|
|
Issue with the VM updating initramfs-tools:
|
|
VM related
Trying to install "systemd" as a dependency tells me this VM is not using systemd as the init system like the way the other unittest RasPiOS on Zero 2 W test VM does. Edit: Correction systemd is being upgraded
but the failure at initramfs-tools
prevents the rest of the update to proceed to the point where systemd-resolve would be started and making use of
breaking DNS name resolution in the VM.
|
|
holta
changed the title
|
Just RasPiOS the ubuntu family already is configured like that so the makes things more uniform across distros. The link is desired for 2 reasons, first the resolver will cache the dns lookups for faster response to subsequent lookups and provides the needed interface zone lookups to enable concurrent working dns when the VPN is active. |
When you say "ubuntu family" here, are you including the wider family e.g. Debian 13 Trixie? (And also Ubuntu 24.04 derivatives like Mint 22, and Trisquel 12?) |
|
The Ubuntu family would include MintOS and perhaps Trisquel. Haven't seen a iiab-diagnostics from Trisquel posted yet. Debian is the bases for RasPiOS so that would included also. The VM test fails because apt upgrade is not preformed before that start of installing IIAB. |
Interesting! 🧩 Tangentially related: |
jvonau
force-pushed
the
resolv
branch
2 times, most recently
from
618f327 to
d5c4e18
Compare
|
@EMG70 would you have time to test[*] this PR on 64-bit RPiOS? Either on "Lite" or "with desktop" ? [*] If you do have time, please test that the WiFi hostpot actually works well in the end 😄 |
|
Failure at ansible collections
potential cause
|
|
https://githubstatus.com confirms... 
|
|
I don't have time to explain the backstory about the "nameserver 127.0.0.53" right now. |
@EMG70 please make sure all apt updates are applied (with a reboot!) before beginning test of this PR, to be extra sure!
|
|
NetworkManager has baked in netplan as a single source of truth in newer releases making things more Ubuntu like in the networking department, just trying to get out in front of future issues. In the past dnsmasq parsed /etc/resolv.conf to gather the information on what upstream dns servers to query for internet websites, it appears that with /etc/resolv.conf now being a symlink the parsing is not preformed as in the past. This is not really a big issue for IIAB and it's usual use of dnsmasq for dns and dhcp for the wifi clients connected via hostapd except for when 'iiab_gateway_enabled=True' there would be no way to make the upstream DNS query. Side notes:
|
jvonau
force-pushed
the
resolv
branch
2 times, most recently
from
3c2f9d3 to
b6f07ef
Compare
|
|
Would be worthy to look at #4067 also given it's 2 month old statnding |
|
@jvonau - Looking at PR #4093's complete changes, I see it achieves: What PR #4093 Achieves:
You can confirm this for me please. |
|
In a nutshell yes, the changes to the VM tests was more of testing to see how the arm runners are configured and to workaround the 'Errors were encountered while processing:", " initramfs-tools' due to the broken VM that is used. The other details that were missed is the change to the unit files:
I just don't feel like articulating the reasoning for the change, I'm sure you can deduce the reason when a looking at #4078. Hint NM still twiddles with the wireless interface so just let NM do that and bring up hostapd later. |
|
You also forgot the DEPRECATION WARNING |
|
Note if the change in 605783c is reverted then NM could render br0 also, one of the reasons for changing the 'After' statement above, a bit of future proofing. I just went with mirroring previous behavior of always using systemd-network with that commit. |
PR #4093 Testing Results - Raspberry Pi Debian TrixieTest Environment
PR #4093 OverviewPR #4093 implements a modern DNS stack with the following components:
Test Results Summary
Detailed Test1. dnsmasq Configurationroot@box:~# cat /etc/dnsmasq.d/dnsmasq-iiab
#IIAB
bind-dynamic
no-resolv
server=127.0.0.53✅ Result: Configuration matches PR #4093 specification 2. systemd-resolved Statusroot@box:~# sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-12-02 10:46:31 EAT; 3h 11min ago
Main PID: 330 (systemd-resolve)
Status: "Processing requests..."✅ Result: systemd-resolved active and running 3. systemd-resolved Listenerroot@box:~# sudo ss -tulnp | grep 127.0.0.53
udp UNCONN 0 0 127.0.0.53:53 0.0.0.0:* users:(("systemd-resolve",pid=330,fd=17))
tcp LISTEN 0 4096 127.0.0.53:53 0.0.0.0:* users:(("systemd-resolve",pid=330,fd=18))✅ Result: Listening on both UDP and TCP port 53 4. dnsmasq Forwarding Configurationroot@box:~# journalctl -u dnsmasq | grep "127.0.0.53"
Dec 02 10:46:37 box dnsmasq[1386]: using nameserver 127.0.0.53#53✅ Result: dnsmasq correctly forwarding to systemd-resolved 5. DNS Resolution Testroot@box:~# dig @10.10.10.10 google.com
; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> @10.10.10.10 google.com
;; ANSWER SECTION:
google.com. 150 IN A 172.217.170.174
;; Query time: 8 msec
;; SERVER: 10.10.10.10#53(10.10.10.10) (UDP)✅ Result: DNS queries resolve successfully with 8ms query time 6. Bridge Statusroot@box:~# ip addr show br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.10.10.10/24 brd 10.10.10.255 scope global br0
root@box:~# bridge link show
5: ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100✅ Result: Bridge UP with correct IP, ap0 enslaved and forwarding 7. DHCP Lease (WiFi Client Connected)root@box:~# cat /var/lib/misc/dnsmasq.leases
1764676958 9e:8f:c5:c3:24:77 10.10.10.69 OPPO-A15 01:9e:8f:c5:c3:24:77✅ Result: WiFi client (OPPO-A15) connected and received IP 10.10.10.69 8. networkd-dispatcher Operationroot@box:~# journalctl -u networkd-dispatcher | grep br0
Dec 02 10:46:29 box NET-DISP-configured br0 no-carrier
Dec 02 10:46:31 box NET-DISP-configured br0 routable✅ Result: networkd-dispatcher detected br0 routable state and triggered services Key Findings✅ What Works
🎯 Architecture Validation
ConclusionPR #4093 is ready for Debian Trixie on Raspberry Pi. All components work as designed:
Related Issues
|
PR #4093 Test Results - Ubuntu 24.04 LTSTest Environment
Test Results
Evidence1. Netplan Configuration$ cat /etc/netplan/60-iiab.yaml
network:
version: 2
renderer: networkd
bridges:
br0:
dhcp4: no
dhcp6: no
addresses: [10.10.10.10/24]2. Bridge Status$ ip addr show br0
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet 10.10.10.10/24 brd 10.10.10.255 scope global br0
$ bridge link show
6: ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> master br0 state forwarding3. systemd-resolved$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Active: active (running)
$ ss -tulnp | grep 127.0.0.53
udp UNCONN ... 127.0.0.53:53 ... systemd-resolve
tcp LISTEN ... 127.0.0.53:53 ... systemd-resolve4. dnsmasq Configuration$ cat /etc/dnsmasq.d/dnsmasq-iiab
#IIAB
bind-dynamic
no-resolv
server=127.0.0.535. dnsmasq Running$ systemctl status dnsmasq
● dnsmasq.service - dnsmasq
Active: active (running)
$ journalctl -u dnsmasq | grep "127.0.0.53"
dnsmasq[1234]: using nameserver 127.0.0.53#536. hostapd$ systemctl status hostapd
● hostapd.service - Hostapd IEEE 802.11 AP
Active: active (running)7. DHCP Client Connected$ cat /var/lib/misc/dnsmasq.leases
1764682585 9e:8f:c5:c3:24:77 10.10.10.69 OPPO-A15 01:9e:8f:c5:c3:24:778. DNS Resolution Working$ dig @10.10.10.10 google.com
;; ANSWER SECTION:
google.com. 150 IN A 172.217.170.174
;; Query time: 8 msec
;; SERVER: 10.10.10.10#53(10.10.10.10)9. networkd-dispatcher Event Logs$ journalctl -u networkd-dispatcher | grep br0
NET-DISP-configured br0 no-carrier
NET-DISP-configured br0 routable
Starting dnsmasq for br0Architecture FlowKey Features Validated
Conclusion✅ PR #4093 VALIDATED - All components functional on Ubuntu 24.04 LTS. |
PR #4093 Test Results - Debian x86-64Test Environment
Test Results
Evidence1. System Info$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_CODENAME=trixie
ID=debian
$ uname -m
x86_642. systemd-networkd Configuration Files$ ls -la /etc/systemd/network/
-rw-r--r-- 1 root root 72 Dec 2 18:00 IIAB-Bridge.netdev
-rw-r--r-- 1 root root 339 Dec 2 18:00 IIAB-Bridge.network
$ cat /etc/systemd/network/IIAB-Bridge.netdev
[NetDev]
Name=br0
Kind=bridge
$ cat /etc/systemd/network/IIAB-Bridge.network
[Match]
Name=br0
[Network]
Address=10.10.10.10/24
LinkLocalAddressing=no
ConfigureWithoutCarrier=yes
RequiredForOnline=degraded-carrier
Domains=lan3. Bridge Status$ ip addr show br0
5: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN
inet 10.10.10.10/24 brd 10.10.10.255 scope global br0
$ networkctl status br0
● 5: br0
NetDev File: /etc/systemd/network/IIAB-Bridge.netdev
Network File: /etc/systemd/network/IIAB-Bridge.network
State: no-carrier (configured)
Address: 10.10.10.10
Search Domains: lan4. systemd-resolved$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Active: active (running)
$ ss -tulnp | grep 127.0.0.53
udp UNCONN ... 127.0.0.53:53 ... systemd-resolve
tcp LISTEN ... 127.0.0.53:53 ... systemd-resolve5. dnsmasq Configuration$ cat /etc/dnsmasq.d/dnsmasq-iiab
#IIAB
bind-dynamic
no-resolv
server=127.0.0.536. dnsmasq Running$ systemctl status dnsmasq
● dnsmasq.service - dnsmasq
Active: active (running)
Dec 02 18:05:41 box dnsmasq[1897]: using nameserver 127.0.0.53#53
Dec 02 18:05:41 box dnsmasq-dhcp[1897]: DHCP, IP range 10.10.10.11 -- 10.10.10.254
Dec 02 18:05:41 box dnsmasq-dhcp[1897]: DHCP, sockets bound exclusively to interface br07. hostapd Status$ systemctl status hostapd
○ hostapd.service - Hostapd IEEE 802.11 AP
Active: inactive (dead) since Tue 2025-12-02 18:06:47 EAT
Dec 02 18:05:35 box hostapd[910]: ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Dec 02 18:05:35 box systemd[1]: Started hostapd.service
Dec 02 18:06:47 box systemd[1]: Stopping hostapd.service
Dec 02 18:06:47 box systemd[1]: Stopped hostapd.service8. networkd-dispatcher$ systemctl status networkd-dispatcher
● networkd-dispatcher.service - Dispatcher daemon for systemd-networkd
Active: active (running)
$ journalctl -u networkd-dispatcher | grep br0
Dec 02 18:05:34 box networkd-dispatcher[902]: NET-DISP-configuring br0 no-carrier
Dec 02 18:05:35 box networkd-dispatcher[938]: NET-DISP-configured br0 routable
Dec 02 18:06:47 box networkd-dispatcher[3088]: NET-DISP-configured br0 no-carrier9. DNS Resolution Working$ dig @10.10.10.10 google.com
;; ANSWER SECTION:
google.com. 245 IN A 172.217.170.174
;; Query time: 12 msec
;; SERVER: 10.10.10.10#53(10.10.10.10)10. NetworkManager Status$ nmcli device status
DEVICE TYPE STATE CONNECTION
wlx44334cb841e2 wifi connected Graphit
br0 bridge connected (externally) br0
enp0s31f6 ethernet unavailable -- 11. DHCP Leases$ cat /var/lib/misc/dnsmasq.leases
(empty - no WiFi clients connected, hostapd stopped)Architecture FlowKey Features Validated
Issues Found
|
|
Note: ap0 is a clone of the wireless device that is present and occurs before NetworkManager or hostapd are started.
The 'externally' denotes that NM didn't start or has control of the interface that is present just like 'lo' reports Would rather see a iiab-diagnostics too much info is being withheld. |
Debian x86-64 Test ResultsDiagnostics ProvidedFull diagnostics: https://paste.centos.org/view/5b572c02 Test Environment
Key Findings1. WiFi Adapter Supports AP Mode ✅root@box:~# iw list | grep -A 10 "Supported interface modes"
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x186e
root@box:~# You were correct - the adapter does support AP mode. 2. can_be_ap Detection Working ✅$ grep can_be_ap /etc/iiab/iiab.ini
can_be_ap = TrueDetection logic correctly identified AP capability. 3. hostapd Behaviorroot@box:~# journalctl -u hostapd -n 50
Dec 03 15:26:25 box systemd[1]: hostapd.service - Access point and authentication server for Wi-Fi and Ethernet was skipped>
-- Boot 4bad5848bea9487db9877fc3b2144151 --
Dec 03 15:44:49 box systemd[1]: Starting hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenti>
Dec 03 15:44:50 box hostapd[929]: ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Dec 03 15:44:50 box systemd[1]: Started hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authentic>
Dec 03 16:55:23 box systemd[1]: Stopping hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenti>
Dec 03 16:55:24 box systemd[1]: hostapd.service: Deactivated successfully.
Dec 03 16:55:24 box systemd[1]: Stopped hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authentic>
root@box:~#
4. Current ap0 Status$ ip link show ap0
Device "ap0" does not exist.5. NetworkManager Status$ nmcli device status
wlx44334cb841e2 wifi connected Graphit
br0 bridge connected (externally) br0
Questions
|
|
@jvonau am I right that wifi_up_down is rpi only? |
I believe Somewhat Related: https://wiki.iiab.io/go/FAQ#Can_I_create_a_Wi-Fi_hotspot_using_an_old_laptop%3F |
|
5b572c02 Think I seen this one while playing with my realtech device, I ended up compiling the driver to get it to work correctly.
So ap0 was present, hostapd started, dnsmasq started, then ap0 went away a full minute later.
The desktop starts later. Think the desktop grabbed the interface to scan for the wifi 'pick list' You sure NetworkManager is running the show? The below shows NM logging to 16:55:48 yet the above connection is at 16.57:03 seems like something else made the connection. NM isn't connecting yet, can't grab the interface because of the above desktop scanning So where did the device at /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/ieee80211/phy0/rfkill0 go? removed from the usb port?
https://forums.raspberrypi.com/viewtopic.php?t=289970
Is there any reason the usb device is switching between usb ports (1-1<->1-2) and phy{1234} out of the blue? |
PR #4093 Test Results - Ubuntu x86-64Test Environment
Test Results
1. System Info$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
VERSION_CODENAME=noble
ID=ubuntu
$ uname -m
x86_642. Netplan Configuration$ ls -la /etc/netplan/
-rw------- 1 root root 129 Dec 3 21:35 60-iiab.yaml
$ cat /etc/netplan/60-iiab.yaml
network:
version: 2
renderer: networkd
bridges:
br0:
dhcp4: no
dhcp6: no
addresses: [10.10.10.10/24]3. Netplan Status$ netplan status
Online state: online
DNS Addresses: 127.0.0.53 (stub)
● 7: wlx44334cb841e2 wifi/"Graphit" UP (NetworkManager)
MAC Address: 44:33:4c:b8:41:e2
Addresses: 192.168.1.75/24 (dynamic, dhcp)
DNS Addresses: 192.168.1.2544. Bridge Status$ ip addr show br0
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN
inet 10.10.10.10/24 brd 10.10.10.255 scope global br0
$ networkctl status br0
● 4: br0
Network File: /run/systemd/network/10-netplan-br0.network
State: no-carrier (configured)
Address: 10.10.10.105. systemd-resolved$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Active: active (running)
$ ss -tulnp | grep 127.0.0.53
udp UNCONN ... 127.0.0.53:53 ... systemd-resolve
tcp LISTEN ... 127.0.0.53:53 ... systemd-resolve6. dnsmasq Configuration$ cat /etc/dnsmasq.d/dnsmasq-iiab
#IIAB
bind-dynamic
no-resolv
server=127.0.0.537. dnsmasq Running$ systemctl status dnsmasq
● dnsmasq.service - dnsmasq
Active: active (running)
Dec 03 21:53:32 box dnsmasq[1451]: using nameserver 127.0.0.53#53
Dec 03 21:53:32 box dnsmasq-dhcp[1451]: DHCP, IP range 10.10.10.11 -- 10.10.10.254
Dec 03 21:53:32 box dnsmasq-dhcp[1451]: DHCP, sockets bound exclusively to interface br08. hostapd Status$ systemctl status hostapd
○ hostapd.service - Hostapd IEEE 802.11 AP
Active: inactive (dead) since Wed 2025-12-03 21:55:01 EAT
Duration: 1min 34.960s
Dec 03 21:53:26 box hostapd[1321]: ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Dec 03 21:53:26 box systemd[1]: Started hostapd.service
Dec 03 21:55:01 box systemd[1]: Stopping hostapd.service
Dec 03 21:55:01 box systemd[1]: Stopped hostapd.service9. networkd-dispatcher$ systemctl status networkd-dispatcher
● networkd-dispatcher.service - Dispatcher daemon for systemd-networkd
Active: active (running)
$ journalctl -u networkd-dispatcher | grep br0
Dec 03 21:53:21 box networkd-dispatcher[1180]: NET-DISP-configured br0 no-carrier
Dec 03 21:53:26 box networkd-dispatcher[1336]: NET-DISP-configured br0 routable
Dec 03 21:55:01 box networkd-dispatcher[3398]: NET-DISP-configured br0 no-carrier10. DNS Resolution Working$ dig @10.10.10.10 google.com
;; ANSWER SECTION:
google.com. 115 IN A 172.217.170.206
;; Query time: 8 msec
;; SERVER: 10.10.10.10#53(10.10.10.10)11. NetworkManager Status$ nmcli device status
DEVICE TYPE STATE CONNECTION
wlx44334cb841e2 wifi connected Graphit
br0 bridge unmanaged --
enp0s31f6 ethernet unmanaged -- ✅ br0 is unmanaged (correct behavior) 12. WiFi Adapter Capabilities$ iw list | grep -A 10 "Supported interface modes"
Supported interface modes:
* AP
* AP/VLAN✅ WiFi adapter supports AP mode 13. ap0 Status$ ip link show ap0
Device "ap0" does not exist.14. DHCP Leases$ cat /var/lib/misc/dnsmasq.leases
(empty - no WiFi clients connected, hostapd stopped)Key Findings✅ What Works
|
|
0b957ee4 and 5b572c02 That chipset/driver doesn't support running both ap and sta at the same time. Running Pi500 Some document fodder for the wiki. |
|
@holta I used https://github.com/lwfinger/rtw88 to compile the driver on RasPiOS https://forums.raspberrypi.com/viewtopic.php?t=315108 |
output for this one : and |
FWIW I would try compiling the above alternate driver, not sure if that would unlock being able to run ap and sta concurrently, the key change to look for is replacing the 'interface combinations are not supported' with 'valid interface combinations' in the |
Good place and flags aren't really needed, just looking at the high level should be enough to identify the attached devices. |
|
Cloning detection but I would rather pursue that in a different issue/PR The other way might be better to grep for 'interface combinations are not supported' and revise the logic, hence lets move that part to a new issue. |
Funny thing is users showing up with random wifi equipment and expecting stuff to just work, #3057 as noted in the wiki, that is how the can_be_ap code came into being. This hardware is the newest corner case with a cloning issue. |
4 participants
Fixes bug:
Might fix #4010 @tim-moody
Description of changes proposed in this pull request:
Use systemd-resolve with NetworkManager just like Ubuntu does
Smoke-tested on which OS or OS's:
RasPiOS trixie
https://paste.centos.org/view/0bb937dd