Hi,
(since this is a long post, i divided it to sections)

TL;DR

I have a networking issue in my Yocto dist; Somehow, my ethernet device won't work with systemd-networkd, but will work with /etc/network/interfaces.

Problem
I have an Nvidia Jetson AGX Xavier device which runs a Yocto Thud distribution based on meta-tegra's tegra-minimal-initramfs, which is a small initrd for Jetson Xavier, except it was modified to run with coreutils instead of busybox, and with systemd.

It has an eth0 device which is configured (with a config file in /etc/systemd/network) with a static IP address. The Xavier's Ethernet port is connected directly to another Ubuntu PC, which is also on the same subnet with a different static IP address.

I cannot get the Xavier's network device to work with systemd-networkd;

Once the device boots into the initrd, it appears as if the network device is configured correctly:

• `ifconfig` shows that eth0 is configured with the correct IP address
• The following messages appear in 'dmesg':
  [   12.390612] gpio tegra-gpio wake20 for gpio=52(G:4)
  [   15.242016] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off

However, when I ping the Ubuntu machine on the other end of the cable, there's no response.

Debugging

• When running tcpdump on the Ubuntu machine, it shows that the Ubuntu machine receives an ARP request, and sends a reply back:

20:00:55.280337 ARP, Request who-has 192.168.13.10 tell 192.168.13.6, length 46
20:00:55.280362 ARP, Reply 192.168.13.10 is-at 3c:fd:fe:81:f1:93 (oui Unknown), length 28
20:00:56.291843 ARP, Request who-has 192.168.13.10 tell 192.168.13.6, length 46
20:00:56.291866 ARP, Reply 192.168.13.10 is-at 3c:fd:fe:81:f1:93 (oui Unknown), length 28

• But, the arp cache on the Xavier is not updated after that; Running 'cat /proc/net/arp' on the Xavier device shows that:

xavier:~$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.13.10    0x1         0x0         00:00:00:00:00:00     *        eth0

 

• There are no iptable rules in the Xavier (according to iptables -L).
• Running 'networkctl status' on the device, shows that its State is "routable (configuring)", however i'm not sure if it's a problem or not, after searching what it means.

 

• I've also tried to look if I somehow installed another networking service that conflicts with systemd-networkd, but it doesn't seem like it:

xavier:~$ systemctl list-units|grep -i net|awk '{print $1}'
sys-devices-2490000.ether_qos-net-eth0.device
sys-devices-virtual-net-dummy0.device
sys-subsystem-net-devices-dummy0.device
sys-subsystem-net-devices-eth0.device
systemd-resolved.service
network-online.target
network.target
nss-lookup.target

Using /etc/network/interface does work

If i 'move' to using /etc/network/interfaces by doing:

1. Running: systemctl stop systemd-networkd.{socket,service}

2. Write an equivalent configuration in /etc/network/interfaces

3. Restart eth0: ifconfig eth0 down; ifconfig eth0 up

Then, all of a sudden the ping works.

My configuration

• In order to use systemd-networkd, I have tried various combinations of the following configuration parameters in my local.conf, after searching various resources on the internet for using systemd on Yocto:

DISTRO_FEATURES_append = " systemd coreutils procps"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
DISTRO_FEATURES_remove = " sysvinit"
PREFERRED_PROVIDER_udev = "systemd"
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow"
#DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
VIRTUAL-RUNTIME_base-utils = "coreutils"
DISTRO_FEATURES_remove += "wayland directfb busybox"
VIRTUAL-RUNTIME_base-utils-syslog = ""
PACKAGECONFIG_append_pn-systemd = "

And none of it seemed to work.

• The following is the non-working systemd network device configuration file:

[Match]
Name=eth0

[Network]
Address=192.168.13.6/24
Gateway=192.168.13.10

• And the following is the working equivalent /etc/network/interfaces file:

auto eth0
iface eth0 inet static
                address 192.168.13.6
                netmask 255.255.255.0

----

I also didn't find a post with similar symptoms.

Does anyone have an idea on how to debug this?

Please accept my apologies if this isn't the right forum, i wasn't sure where to sent it to.

Thanks,

Eliran

On Mon, Sep 14, 2020 at 11:31 AM eliranl via lists.yoctoproject.org
<eliranl=amazon.com@lists.yoctoproject.org> wrote:

Hi,
(since this is a long post, i divided it to sections)

TL;DR

I have a networking issue in my Yocto dist; Somehow, my ethernet device won't work with systemd-networkd, but will work with /etc/network/interfaces.

Problem
I have an Nvidia Jetson AGX Xavier device which runs a Yocto Thud distribution based on meta-tegra's tegra-minimal-initramfs, which is a small initrd for Jetson Xavier, except it was modified to run with coreutils instead of busybox, and with systemd.

Which of the meta-tegra branches is it? thud-l4t-r32.3.1?

It has an eth0 device which is configured (with a config file in /etc/systemd/network) with a static IP address. The Xavier's Ethernet port is connected directly to another Ubuntu PC, which is also on the same subnet with a different static IP address.

I cannot get the Xavier's network device to work with systemd-networkd;

[...]

The following is the non-working systemd network device configuration file:

[Match]
Name=eth0

[Network]
Address=192.168.13.6/24
Gateway=192.168.13.10

There was an issue with NVIDIA's eqos driver in older BSPs. I know it
affected the TX2, with the exact same symptoms
It could affect Xavier modules as well. The workaround is to disable
LLDP on by adding

LLDP=no

to the [Network] section for the interface.

See https://github.com/OE4T/meta-tegra/issues/146

The workaround didn't get back-ported to the thud-l4t-r32.3.1 branch.

[...]

Please accept my apologies if this isn't the right forum, i wasn't sure where to sent it to.

Since this is BSP-related, opening an issue at
https://github.com/OE4T/meta-tegra/issues might work better.

Regards
-Matt

Thanks Matt!! This solved it.

And yes, the branch is thud-l4t-r32.3.1.