Communications issue with Xavier NX Ethernet

[s.hall]

Hi Forum

I have a very strange problem communication issue with my Xavier NX.
I require a static IP or something similar that allows me to ssh into the device each day.

Story
Initially, when I had installed Jetpack 4.6.1, I put a config file under /etc/network/interfaces.d/eth0
telling it to use 192.168.0.xxx. This would consistently work for me.
How am I connecting on Jetpack 4.6.1?
The Xavier is plugged into the office network via ethernet cable, and I can ssh over wifi or ethernet, whatever happens to be most convenient at the time.

However, since I upgraded to Jetpack 5 I can’t communicate with the Xavier anymore in the same way.
I installed netplan (because for some reason it isn’t provided in Jetpack 5??) and tried to configure a static IP using a netplan config file.

Behaviour:

• I can’t ping or ssh into the Xavier on the known static IP address.
• I’ve confirmed the devices I’m using to communicate are on the same subnet.
• When connected through the building network, I can’t see any packets on Wireshark

The only successful way I can connect over the network is if I bypass the building network and plug it straight into my computer using an adapter. This is not acceptable when I need to deploy this device in the field.

Apologies if this post lacks necessary information. Happy to answer any questions if clarification is needed.

[WayneWWW]

Is this on Xavier NX or AGX? You filed on AGX forum.

[s.hall]

Xavier NX

[kayccc]

Moving this topic to Xavier NX forum.

[s.hall]

Hi everyone just wanted to add some clarification

I currently have a network communication issue which is only present on L4T-35.1.0. Unfortunately our software is depending on this version of L4T.

In terms of environment/setup, I have an local (isolated from office) network the Xavier NX is on with an access point for my laptop. The access point is a GL-AR750S on IP address 192.168.1.1. I can ping all 4 devices on this network (192.168.1.201, 192.168.1.202, 192.168.1.203, 192.168.1.204, all netmask 255.255.0.0) everything on this isolated network except the Xavier NX (192.168.1.236).

Previously (on L4T-32.7.1) I have used the following file under /etc/network/interfaces.d/eth0

auto eth0

iface eth0 inet static
address 192.168.1.236
netmask 255.255.255.0
gateway 192.168.0.1

However, this approach does not work in L4T-35.1.0. The ethernet interface remains in the “down” state after boot if I use this method.
So I installed netplan and placed the following yaml file under /etc/netplan/networkConfig.yaml.
However this didn’t fix the issue. “Ifconfig” says the interface is up, and I have the static IPv4 address. However I still can’t ping anything else on this isolated network.

network:
    version: 2
    renderer: NetworkManager
    ethernets:
        eth0:
            dhcp4: no
            addresses: [192.168.1.236/16]
            nameservers:
                addresses: [192.198.1.0, 192.168.1.1, 8.8.8.8]
            routes:
            - to: default
              via: 192.168.1.0

This is the output of nmcli

eth0: connected to netplan-eth0
        "eth0"
        ethernet (nvethernet), 48:B0:2D:76:36:3F, hw, mtu 1500
        ip4 default
        inet4 192.168.1.236/16
        route4 192.168.0.0/16
        route4 0.0.0.0/0
        inet6 fe80::4ab0:2dff:fe76:363f/64
        route6 fe80::/64

This is the output of route -n

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.0     0.0.0.0         UG    20100  0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 docker0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.0.0     U     100    0        0 eth0

I really need help on this issue. Would be very grateful for any advice.

[WayneWWW]

Please remove the micro usb cable on the jetson in case the usb network causes some effect on your network.

[s.hall]

Hi Wayne

Thanks for responding.
I tried this and unfortunately, it was unsuccessful.

Thanks

[WayneWWW]

Is your NX able to work if it is connected to an environment with dhcp server to assign a IP?

[s.hall]

Hi Wayne

Yes it can

[WayneWWW]

So if I connect two jetson on a hub and assign staic IP to both of them manually, I shall reproduce this issue?

[s.hall]

Hi Wayne

Yes, I think that would replicate my setup.

[s.hall]

From the nmcli output, the route4 and inet4 subnets don’t match. Is this relevant to the problem? I thought I had set this in the netplan yaml file.

[s.hall]

Hi @WayneWWW

Did you get a chance to look at this issue yet? What was the result?

[linuxdev]

Yes, this is relevant. Always include both the ifconfig (or ip -s addr) and route output.

[ben.steer]

Hello, I am working with @s.hall on this issue and have more context and details to provide following further investigation. Note that we are regular customers and ship production units with NVIDIA Jetson products.

We have a custom carrier board we are trialling for our Xavier NX which is heavily based on the Antmicro Jetson Baseboard (GitHub - antmicro/jetson-nano-baseboard: Antmicro's open hardware baseboard for the NVIDIA Jetson Nano, TX2 NX and Xavier NX) which breaks out 2-pair ethernet and gigabit ethernet separately. We need to deploy in an integrated system where only the 2-pair ethernet is connected at 100Mbs through an embedded router, and gigabit is not an option.

Currently when we boot the Xavier in this setup, it autonegotiates full duplex gigabit ethernet, even though the gigabit pairs are not connected. It can’t be pinged via its static IP address, and the router doesn’t show it as a connected client. The following is output from ethtool:

And the following is output from ifconfig:

We can replicate similar failure behaviour in bench testing (no integrated system involved) by connecting only the 2-pair ethernet from the carrier board through a simple network switch. Again, gigabit is autonegotiated for some reason, and it cannot be communicated with. It has the following output from ethtool:

And the following ifconfig output:

If we force 100Mbs ethernet with “sudo ethtool -s eth0 autoneg off speed 100” in bench testing, the issue is resolved and 100Mbs works, and we can communicate with the board. We can even automate the ethtool commands using a networkd-dispatcher script. The following is the output from ethtool after the change:

And the following is ifconfig output after the change:

However, when we try this forced 100Mbs fix in the integrated router setup, it is unsuccessful. It has the following output from ethtool:

And the following output from ifconfig:

Output from dmesg indicates the link is repeatedly up and down:

Every time the link tries to go up, the orange LED on the carrier board flashes once, and this occurs every few seconds. If you catch ifconfig at the right time, you can see the static IP has been assigned, but the majority of the time it is not.

When we try the exact same setups and carrier board, but use a Xavier NX flashed with Jetpack 4.6.1, the connection is fine and we can ping and ssh the board. We noticed that ethtool reports the driver for 4.6.1 being eqos whereas it is nvethernet for Jetpack 5.1.

Note that the system works fine and can be pinged when the gigabit lines are connected.

The following is the netplan config used in these tests:

We are preparing an integrated system for a demonstration and need to resolve this quite urgently. We would appreciate any ideas on this one.

[ben.steer]

Investigating a bit further, it seems the Jetpack 4.6.1 Xavier succeeds in this setup because it has autonegotiated 10Mbs, but if we try to set it to 100Mbs it fails also. Will investigate the hardware we are routing ethernet through. But, still strange that the Jetpack 5.1 setup can’t autonegotiate a valid speed. The following is the ethtool output on eth0 for the JP 4.6.1 Xavier in the integrated setup:

[WayneWWW]

Is this reproducible with Xavier NX devkit instead of your custom board?

[ben.steer]

No, not when using the dev kit. Perhaps if a cable were used that didn’t connect the gigabit lines, it may be reproducible.

[linuxdev]

Is 192.168.1.0 your router?

[s.hall]

The router’s address is 192.168.1.1