Systemd-networkd controlling ethernet on Jetpack 4.2.2

Hi,

By default in Jetpack 4.2.2 DHCP lease is obtaining using dhclient, albeit systemd-networkd is available on system. Is there known problems using systemd as DHCP client, as I am bit puzzled how things work currently.

If i configure systemd-networkd to manage network interfaces, and write specific configuration for ethernet to lease IP from DHCP Server, systemd-networkd reports constantly that ethernets status is “degraded configuring” and IP from server is not received. If I stop systemd-networkd daemon completely, and try to lease IP with dhclient, it fails also, which I find pretty odd as well.

With Jetpack 3.1 above systemd-networkd leasing the IP from server was working fine.

Has anyone else encountered this kinda of behaviour ?

I couldn’t answer, but some of networking tends to be through NetworkManager, and NetworkManager works differently than the older purely systemd did. Have you tried the tool “sudo nm-connection-editor”? If this doesn’t do the job, then you might consider posting your “ifconfig”, “route”, and “sudo ethtool -i eth0” outputs.

I have tried to reproduce this with PC with 18.04 and issue is not present there.

Default case where network is working (default settings on Jetpack)

ifconfig eth0:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.112  netmask 255.255.252.0  broadcast 192.168.3.255
        inet6 fe80::b498:16b4:47b6:576  prefixlen 64  scopeid 0x20<link>
        ether 00:04:4b:8c:fd:b1  txqueuelen 1000  (Ethernet)
        RX packets 25863  bytes 37390545 (37.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4055  bytes 331972 (331.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41  

route:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 eth0
default         _gateway        0.0.0.0         UG    32766  0        0 l4tbr0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.252.0   U     100    0        0 eth0
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 l4tbr0

ethtool:

driver: eqos
version: 
firmware-version: 
expansion-rom-version: 
bus-info: 2490000.ether_qos
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

networkctl states that all interfaces that are present are not controlled by systemd-networkd.

WARNING: systemd-networkd is not running, output will be incomplete.

IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           n/a         unmanaged 
  2 dummy0           ether              n/a         unmanaged 
  3 eth0             ether              n/a         unmanaged 
  4 wlan0            wlan               n/a         unmanaged 
  8 l4tbr0           ether              n/a         unmanaged 
  9 rndis0           ether              n/a         unmanaged 
 10 usb0             ether              n/a         unmanaged 

7 links listed.

But as I want to use systemd-networkd, I first disable the eth0 by executing ifconfig eth0 down.
Next I create /run/systemd/network directory and place eth0.network file there. Contents of the file are as follows:

[Match]
Name=eth0

[Network]
DHCP=ipv4

After starting systemd-networkd:

IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 dummy0           ether              off         unmanaged 
  3 eth0             ether              no-carrier  configuring
  4 wlan0            wlan               dormant     unmanaged 
  8 l4tbr0           ether              routable    unmanaged 
  9 rndis0           ether              degraded    unmanaged 
 10 usb0             ether              degraded    unmanaged 

7 links listed.

After a while I execute networkctl again:

IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 dummy0           ether              off         unmanaged 
  3 eth0             ether              degraded    configuring
  4 wlan0            wlan               dormant     unmanaged 
  8 l4tbr0           ether              routable    unmanaged 
  9 rndis0           ether              degraded    unmanaged 
 10 usb0             ether              degraded    unmanaged 

7 links listed.

And it stays there till I reboot the system.

ifconfig states that eth0 does not have IP, route is naturally gone, and ethtool says samethings as default setup:

ifconfig eth0: 

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::b498:16b4:47b6:576  prefixlen 64  scopeid 0x20<link>
        ether 00:04:4b:8c:fd:b1  txqueuelen 1000  (Ethernet)
        RX packets 30284  bytes 41407978 (41.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4870  bytes 428637 (428.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41  

route:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    32766  0        0 l4tbr0
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 l4tbr0

ethtool:

driver: eqos
version: 
firmware-version: 
expansion-rom-version: 
bus-info: 2490000.ether_qos
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

miitool states that physical link however is ok:

eth0: negotiated 1000baseT-FD flow-control, link ok

I have not touched connection editor as I did not need to do that on PC either which was running 18.04 so I am assuming that it should not be the case here either.

I am bit puzzled about this. I cannot access DHCP server logs however, so I am not sure if there has been actual request to server or not, and whether server has answered anything to Jetson. So that is the next step to check. There has been some discussions that systemd might reject some DHCP offers if not all necessary options that were request were not present, but as x86-64 18.04 is works against same server, server should honor requested options.

Sorry, bit lengthy post because of logs.

I can’t answer, and I suspect one would need to sit there at the specific unit and experiment. However, it seems that NetworkManager will probably still have its own setup as to whether or not it is to do management. It is likely that NetworkManager and systemd are competing…enabling systemd is not necessarily the same thing as disabling NetworkManager. See this, find out if NetworkManager was actually disabled:
http://xmodulo.com/disable-network-manager-linux.html

Before you do that I suggest actually running “sudo nm-connection-editor” and seeing what this tool still sees. Possibly you could mark what you want to occur in this tool and get the result you want.

“systemd” setup in a desktop differs somewhat from NVIDIA embedded systems. I do not know in what ways, but for example run level setup differs since boot itself differs. “systemd” behavior on the desktop PC is not necessarily an example of how systemd should work on a Jetson.

Also, if you did something to change control to systemd, and if systemd was not configured for DHCP (and if systemd never was set up for use, then there is no reason DHCP software would be set up), then things might be working to the extent it was told to work. Try manually running “sudo dhclient”. If this works, then it is only the lack of DHCP setup which is an issue.

Disabling network manager does not make a difference, issue remains as the same.
Well need to debug this further, i’ll make an update when something new arises.

Did “sudo dhclient” cause an IP address to be issued? If not, then this is probably the point to start debugging at since configuration can be made to either ignore or to not ignore DHCP.

Aaand sorry for late reply :(

Issue was that DHCP server did not like client identifier which was sent by systemd.

Adding:
[DHCP]
ClientIdentifier=mac

to network definition solved this issue.

Edit: This depends on DHCP server, PFSense did not have any problems, but Asus router actually had problems with the default identifier.