BSP 6.x systemd-networkd issues


BSP 6.x is currently using systemd 250 (250.5+). It broke network sharing like this

Name=wlan0 uap0


Though random host address ( is granted, sharing interface gets assigned IP from one subnet and Wi-Fi clients receive IP addresses form different subnet. This worked properly with older BSP (5.x) and older systemd 244.x.

WLANInterfaceType=“ap” got broken as well. This assignment should limit .network file match to WLAN cards operating only in AP mode. Some USB cards still seem working, but not one on Colibri iMX6ULL WiFi. With WLANInterfaceType=“ap” specified in .network file, uap0 is listed as unmanaged by networkctl and doesn’t receive IP.

Looks like BSP Layers and Reference Images for Yocto Project Issue Tracker stopped mentioning Yocto version used. I’d like to know when to expect fixed Yocto or just systemd version.


Hello @Edward ,

Thanks for bringing up this to our attention. We will try to reproduce this behavior and come back to you as soon as we have new information.

The best place to see the Yocto versions that are used for a specific BSP release is the Release Matrix:

Best regards,

Thanks. Looks like I need to wait couple of years to see it fixed or upgrade Yocto myself.

Hello @Edward, could you share more details about this setup? Do you run hostapd as well or is systemd-networkd supposed to do everything automatically to create the AP?
Are there other configurations that are necessary to reproduce it?
I ask because I quickly tried it here and my wifi interface didn’t get any IP address configured so it seems that I’m seeing something different from you.

Hello @rafael.tx,

Yes, WLAN AP needs hostapd and WLAN STA needs wpa_supplicant. systemd-networkd task is to care about IP assignment, DHCP client/server tasks, DNS, etc. It’s pity systemd upgrade broke existing features.

I managed to get the network forwarding working. The problem is not that systemd is broken, but our kernel defconfig is missing some options to enable NAT and the demo image is missing a config option in systemd itself to enable the use of NAT. I applied two patches:

In meta-toradex-bsp-common:

diff --git a/recipes-kernel/linux/linux-toradex-mainline-git/defconfig b/recipes-kernel/linux/linux-toradex-mainline-git/defconfig
index 3c6bbc0..d86a5e9 100644
--- a/recipes-kernel/linux/linux-toradex-mainline-git/defconfig
+++ b/recipes-kernel/linux/linux-toradex-mainline-git/defconfig
@@ -59,6 +59,12 @@ CONFIG_INET=y

In meta-toradex-demos:

diff --git a/recipes-core/systemd/systemd_%.bbappend b/recipes-core/systemd/systemd_%.bbappend
index 802daa2..0b22319 100644
--- a/recipes-core/systemd/systemd_%.bbappend
+++ b/recipes-core/systemd/systemd_%.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS:prepend := "${THISDIR}/systemd:"
 SRC_URI += "file://"
-PACKAGECONFIG:append = " networkd"
+PACKAGECONFIG:append = " networkd iptc"
 PACKAGECONFIG[acl] = "-Dacl=true,-Dacl=false,acl"

If you rebuild with these patches you should be able to get the forwarding working with your config file. I don’t know if it’s necessary or not, but I also added IPMasquerade=yes to mine:

root@colibri-imx6ull-06738043:~# cat /lib/systemd/network/ 
Name=wlan0 uap0


The uap0 interface still has more than one IP address:

root@colibri-imx6ull-06738043:~# ip a show uap0
6: uap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c0:e4:34:2f:d4:b7 brd ff:ff:ff:ff:ff:ff
    inet brd scope global uap0
       valid_lft forever preferred_lft forever
    inet brd scope global uap0
       valid_lft forever preferred_lft forever
    inet6 fe80::c2e4:34ff:fe2f:d4b7/64 scope link 
       valid_lft forever preferred_lft forever

And my client received an IP address on the .15 network:

root@verdin-imx8mp-07330987:~# ip a show mlan0
6: mlan0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:6f:24:4f:56:23 brd ff:ff:ff:ff:ff:ff
    inet brd scope global mlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::366f:24ff:fe4f:5623/64 scope link 
       valid_lft forever preferred_lft forever

And the routes are configured properly on the client side:

root@verdin-imx8mp-07330987:~# ip route show
default via dev mlan0 via dev mlan0 dev usb0 proto kernel scope link src dev mlan0 proto kernel scope link src dev mlan0 scope link 

Please let me know if this works for you too.

Hi @rafael.tx,

Thanks for looking at it.

I used it with two kernels, old one 5.4 and LF5.15.52_2.1.0, both with required NF settings enabled, both work well with older systemd.

This may explain why IPMasquerade=yes didn’t work, so I had to iptables my self. But my issue, as I said, was regarding WLANInterfaceType=ap for uap0 on iMX6ULL and Address= for any kind of WLAN card.

So I don’t see what could make it working for you. Definitely it was not systemd iptc option and not kernel config.

What from came your second IP4 address? Are you sure was from systemd? Is connman disabled? With former systemd, uap0 IP assignment was happening after hostapd service started. Is it the same in your case? Is uap0 IP removed on systemctl stop hostapd and assigned again on systemd start hostapd? Is this newly assigned IP due from systemctl start hostapd belongs to the same subnet like new AP clients?

Thanks. I’ll recheck it when time permits.


P.S. I tried 5.15 kernel from NXP, because this one on linux-toradex.git seems having lot of issues, FEC may not work, NAND issues, while the same on LF5.15.52_2.1.0 works on anything starting from VF, just add missing device trees and config files).

Update: Looks like random AP IP is assigned correctly once after boot up. If I do systemctl stop, then start hostapd, issue comes back. So only first time AP is started properly, needs to reboot if user decides to switch AP on after switching it off. Trying commands like networkctl reload doesn’t help. So I see two choices - either changing systemd version or using static AP IP, which would have chances to conflict with wired LAN IP’s.
Regarding two AP IP’s, sometimes I see it like you on BSP 5.7.x, but only first time after boot. Restarting hostapd always seems assigning single random IP.

Connman is not active on the module.
This is the content of my /lib/systemd/network/ file:

root@colibri-imx6ull-06738043:~# cat /lib/systemd/network/ 
Name=wlan0 uap0


With this, the uap0 interface gets a random IP address and is properly setup for forwarding in my IMX6ULL.

I did some quick test and it seems that after killing hostapd and starting it again the network doesn’t work properly. Is this something you need to do on your application?
I also noticed that after this start / stop cycle of the hostapd and a reboot, the uap0 interface came up with just one IP address, but everything else worked as before.

Here’s also an output from networkctl:

root@colibri-imx6ull-06738043:~# networkctl 
  1 lo    loopback carrier     unmanaged
  2 eth0  ether    routable    configured
  3 sit0  sit      off         unmanaged
  4 can0  can      off         unmanaged
  5 mlan0 wlan     off         unmanaged
  6 uap0  wlan     routable    configured
  7 usb0  gadget   routable    configured

7 links listed.

Yes, telling user about unavoidable reboot just because he did shut AP down and wants to start it again - is not good option. It worked well without reboot on BSP 5.7.x.

It’s weird WLANInterfaceType=ap/station works for you. In my case it leads to both mlan0 and uap0 reported as unmanaged by networkctl, as soon WLANInterfaceType appears in corresponding .network files. Since this .network file setting keeps working with non-NXP WLAN cards, looks like systemd has changed something in STA/AP detection, so that it may fail with some drivers.

We can leave it as for not, I have reuired workarounds.

Speaking about Wi-Fi, is it possible to remove outdated regdb recipe from here:


BSP includes 2022 recipe on different path, which builds in to image just fine with above recipe removed.