Jetson AGX Xavier Ethernet connection not working

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,
I’m having trouble connecting to the network via the Ethernet port on my dev kit. I am able to access the internet if I connect via the USB bridge (l4tbr0). I connected the kit to a display and I can see that the ui is constantly switching between connected and disconnected.

Here is the output of head -n 1 /etc/nv_tegra_release

R32 (release), REVISION: 7.2, GCID: 30192233, BOARD: t186ref, EABI: aarch64, DATE: Sun Apr 17 09:53:50 UTC 2022

Below is the output of dmesg | tail

[ 1345.194105] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[ 1346.307302] eqos 2490000.ether_qos eth0: Link is Down
[ 1353.282653] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[ 1354.401831] eqos 2490000.ether_qos eth0: Link is Down
[ 1361.216944] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[ 1362.328637] eqos 2490000.ether_qos eth0: Link is Down
[ 1369.183146] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[ 1370.297321] eqos 2490000.ether_qos eth0: Link is Down
[ 1377.265818] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[ 1378.391897] eqos 2490000.ether_qos eth0: Link is Down

Below is the output for ifconfig -a eth0

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet6 fe80::91d3:1c1f:f93:b869  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:63:bd:99  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 876  bytes 130664 (130.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41

I have confirmed that there is no issue with the LAN cable I am using.

Would really appreciate your help in debugging the issue.

Thanks,
Hara

2

It is an IPv6 address, which Linux (in general, not just Jetsons) have sometimes had issues with. What is the output of the “route” command? It requires a combination of “ifconfig” and “route” to know if basic config works.

3

route gave me this

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
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 l4tbr0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 l4tbr0
4

Looks like it cut off the “Metric” and content further to the right. The full route command would be useful (mouse copy and paste might be missing some of it).

I can see from the route command which was pasted that the IP addresses are all IPv4. It might be of interest to force the ethernet to IPv4. Try running “sudo nm-connection-editor” (you might need to “sudo apt-get install network-manager-gnome”), selecting eth0, clicking the “gear” icon in the lower left to edit, and in the IPv4 tab check “Require IPv4 for this connection to complete”. Then reboot. I don’t know if this will help, but if it runs IPv4 the case is simplified.

5

I ran route > route_output.log
route_output.log (419 Bytes)
It has the same info I copy pasted earlier

I have had “Require IPv4 for this connection to complete” option checked this whole time…

6

Not sure if this is useful info but, when I ran nmtui, I entered the “Activate Connection” menu and noticed that the option for eth0 is constantly changing from Activate to Deactivate

7

I don’t know about the reason for Activate or Deactivate.

Is this using just wired, or is it also using WiFi? I ask because the metric for the default route is quite high, and it only basically shows bridging, which I would not expect if going over wired. It appears eth0 is not ever used due to route. This tends to be validated by the earlier ifconfig showing only a tiny amount of TX bytes, and zero RX bytes. Just a wild guess, but I’d think now that the “Deactivate” is due to WiFi kicking in and displacing wired.

8

No, I don’t have wifi on my kit.

Here is the output of ifconfig -a

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:fe:49:6e:48  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dummy0: flags=130<BROADCAST,NOARP>  mtu 1500
        ether d2:bc:ad:3a:71:9a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet6 fe80::91d3:1c1f:f93:b869  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:63:bd:99  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 85137  bytes 12718072 (12.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41

l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.55.1  netmask 255.255.255.0  broadcast 192.168.55.255
        inet6 fe80::1  prefixlen 128  scopeid 0x20<link>
        ether 82:39:e2:7f:39:85  txqueuelen 1000  (Ethernet)
        RX packets 9804381  bytes 562089181 (562.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29483926  bytes 41732555693 (41.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1613028  bytes 40581187805 (40.5 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1613028  bytes 40581187805 (40.5 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::8039:e2ff:fe7f:3985  prefixlen 64  scopeid 0x20<link>
        ether 82:39:e2:7f:39:85  txqueuelen 1000  (Ethernet)
        RX packets 9772168  bytes 556508063 (556.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29508778  bytes 43447190349 (43.4 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::8039:e2ff:fe7f:3987  prefixlen 64  scopeid 0x20<link>
        ether 82:39:e2:7f:39:87  txqueuelen 1000  (Ethernet)
        RX packets 32228  bytes 5583053 (5.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10486  bytes 880116 (880.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I also checked by disconnecting the bridge and I keep seeing the same issue. The Link is constantly switching between connected and disconnected. Is this a hardware issue?

9

What I see is that the integrated eth0 and the USB usb0 both have IPv6 addresses assigned. The USB has significant traffic, while eth0 has only TX packets. I see no form of error for eth0 RX, but I also see absolutely no RX packets. Is the eth0 address assigned by a router, or is it static? If it were using the default of a router, then the DHCP itself should have caused some RX packets when it got its address. There is a possibility that there is a hardware error on the RX wires (possibly a cable or connector issue), but I don’t know how the adapter would have got its address over DHCP and not have any RX packets (I suppose at that lower level it might not log the packets, but it seems improbable).

10

The eth0 address is assigned by a router. It is connected to the local network in our lab.

11

Unless the problem is one of IPv6, then I do not know why it is not receiving packets, other than possibly hardware failure. I always suspect IPv6 bugs, but since you have a USB NIC working with IPv6, it seems likely that all IPv6 software requirements are available (e.g., kernel features). Or perhaps if the router is managed (or goes through a managed switch or firewall), then perhaps it is just a security check. To verify cables though, does it work if you swap the cable going from USB NIC with that of the integrated NIC?

12

I’m using the in-built ethernet bridge that has a USB-Type C connector. I used multiple LAN cables that I knew were working with other devices to test this issue. I didn’t get a different result with any of them.

13

I’m not sure what the “in-built ethernet bridge that has a USB-Type C connector” means. What I am getting at is that one ethernet device apparently works (the USB adapter), and another, eth0 (direct wired ethernet port) does not “fully” work. If there are two cables, then without switching the remote end, switch the plug in of the USB unit ethernet wire to the eth0 port, and switch the eth0 port’s wire at the local end to the USB. See if swapping just those two connectors works.

14

I cannot do that since one is an RJ45 cable and the other a USB cable that is connected to my local PC.
I have configured the l4tbr0 to see my PC as a gateway and I am able to access the internet through this configuration. Only when I make this configuration does the usb0 and rndis0 devices show up in ifconfig.
Please see this thread Xavier - USB network configuration - #7 by michael.c.proicou

15

The above might explain it. Is the RJ45 on the USB adapter directly connected to the PC? Or does it go through a switch? If direct, then it likely needs to instead go through a “crossover” cable (or an adapter to make it look like a crossover cable). Many devices do not automatically detect mismatched RX/TX. It depends on the features supported in the hardware at both ends of the connection.

If this really goes with ethernet between USB and host PC, without a switch, could you try with a switch in-between?

16

Apologies, looks like I’m not doing a good job of explaining my setup. Let me try again.

There is no separate USB adapter device used. I have connected the Xavier to my Linux machine with the USB 3.0 Type-A to Type-C cable it was shipped with. I have configured the Xavier to access the internet through this connection. I did it by following the link I posted in my last response. I realised this is a possibility because the SDKManager does the same thing when flashing new software.

Now, I have a LAN cable coming from a network port in my lab connected to the ethernet port on the Xavier. The ethernet connection is completely unstable as seen from my previous posts. The dmseg output I pasted in my first post captures the instability perfectly.

  • I have checked using multiple LAN cables that I know are fine

  • I disconnected the USB 3.0 Type-A to Type-C cable and kept only the LAN cable connected

The issue was not resolved in either of these experiments.

I hope this clears up the confusion on USB adapter and makes clear the setup I am working with.

17

Ok, yes, that is the device mode emulation. On the Jetson it should produce address 192.168.55.100, and on the host PC it should produce address 192.68.55.1. This is via scripts in “/opt/nvidia/l4t-usb-device-mode/”. What do you see from:
sudo systemctl status nv-l4t-usb-device-mode.service

If this is running, then it should show up, but you’d have to use the correct USB connector. It would be the USB-C next to the 40-pin header.

I don’t know if the particular original log mention of 2490000.ether_qos is for USB or not, but it might be. If you are at the host PC side, and you monitor “dmesg --follow”, what shows up as you plug in the USB? Sometimes the host PC needs to be told to allow the device to be used (for security reasons). A log might indicate if this is the case (a device plugin would be visible even if the device is not allowed to operate).

18

The device emulation mode works perfectly fine. No issues for me on that front.

I don’t know if the particular original log mention of 2490000.ether_qos is for USB or not, but it might be

It definitely is not. Please see below the output of dmesg | tail after disabling the device mode emulation.


[602860.217200] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow con$
[602861.334634] eqos 2490000.ether_qos eth0: Link is Down
[602868.250299] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow con$
[602869.366329] eqos 2490000.ether_qos eth0: Link is Down
[602876.218058] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow con$
[602877.335066] eqos 2490000.ether_qos eth0: Link is Down
[602884.189020] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow con$
[602885.303794] eqos 2490000.ether_qos eth0: Link is Down
[602891.993792] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow con$
[602893.104741] eqos 2490000.ether_qos eth0: Link is Down

For added measure, I am also sharing the output from dmesg --follow

[602575.204372] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602576.327075] eqos 2490000.ether_qos eth0: Link is Down
[602583.053794] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602584.170019] eqos 2490000.ether_qos eth0: Link is Down
[602590.859967] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602591.970985] eqos 2490000.ether_qos eth0: Link is Down
[602598.660915] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602599.771927] eqos 2490000.ether_qos eth0: Link is Down
[602606.558909] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602607.677743] eqos 2490000.ether_qos eth0: Link is Down
[602614.484445] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602615.604537] eqos 2490000.ether_qos eth0: Link is Down
[602622.393863] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602623.510296] eqos 2490000.ether_qos eth0: Link is Down
[602630.200286] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602631.311259] eqos 2490000.ether_qos eth0: Link is Down
[602638.336907] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602639.447780] eqos 2490000.ether_qos eth0: Link is Down
[602646.137755] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602647.248777] eqos 2490000.ether_qos eth0: Link is Down
[602654.023928] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602655.133540] eqos 2490000.ether_qos eth0: Link is Down
[602661.862941] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602662.976500] eqos 2490000.ether_qos eth0: Link is Down
[602669.788757] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602670.903290] eqos 2490000.ether_qos eth0: Link is Down
[602676.163396] tegra-xudc-new 3550000.xudc: ep 3 disabled
[602676.163430] tegra-xudc-new 3550000.xudc: ep 2 disabled
[602676.163450] tegra-xudc-new 3550000.xudc: ep 5 disabled
[602676.163472] tegra-xudc-new 3550000.xudc: ep 4 disabled
[602676.163490] tegra-xudc-new 3550000.xudc: ep 7 disabled
[602676.163524] tegra-xudc-new 3550000.xudc: ep 9 disabled
[602676.163553] tegra-xudc-new 3550000.xudc: ep 13 disabled
[602676.163580] tegra-xudc-new 3550000.xudc: ep 8 disabled
[602676.163598] tegra-xudc-new 3550000.xudc: ep 15 disabled
[602676.163886] android_work: sent uevent USB_STATE=DISCONNECTED
[602676.163967] tegra-xudc-new 3550000.xudc: ep 11 disabled
[602676.163986] tegra-xudc-new 3550000.xudc: ep 6 disabled
[602676.168519] l4tbr0: port 1(rndis0) entered disabled state
[602676.168874] l4tbr0: port 2(usb0) entered disabled state
[602676.354560] ucsi_ccg 1-0008: port0 evt: Type-C Port Disconnect Detected
[602676.356423] ucsi_ccg 1-0008: [typec-port0] Cable state:0, cable id:1
[602676.358939] tegra-xudc-new 3550000.xudc: vbus state: 0
[602676.358952] tegra-xudc-new 3550000.xudc: device mode off: 0
[602676.358994] tegra-xudc-new 3550000.xudc: active: 1 => 0
[602676.359005] tegra-xudc-new 3550000.xudc: entering ELPG
[602676.359372] tegra-xudc-new 3550000.xudc: entering ELPG done
[602677.591946] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602678.704084] eqos 2490000.ether_qos eth0: Link is Down
[602685.392886] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602686.505192] eqos 2490000.ether_qos eth0: Link is Down
[602687.076524] tegradc 15200000.nvdisplay: unblank
[602687.078371] tegra_nvdisp_handle_pd_enable: Unpowergated Head0 pd
[602687.078644] tegra_nvdisp_handle_pd_enable: Unpowergated Head1 pd
[602687.087607] Parent Clock set for DC plld3
[602687.093655] tegradc 15200000.nvdisplay: hdmi: tmds rate:154000K prod-setting:prod_c_hdmi_111m_223m
[602687.133429] tegradc 15200000.nvdisplay: unblank
[602687.133452] tegradc 15210000.nvdisplay: blank - powerdown
[602687.133466] tegradc 15220000.nvdisplay: blank - powerdown
[602693.193891] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602694.306188] eqos 2490000.ether_qos eth0: Link is Down
[602701.368360] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602702.484422] eqos 2490000.ether_qos eth0: Link is Down
[602709.132585] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602710.243525] eqos 2490000.ether_qos eth0: Link is Down
[602717.269129] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602718.380009] eqos 2490000.ether_qos eth0: Link is Down
[602725.253636] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602726.369740] eqos 2490000.ether_qos eth0: Link is Down
[602733.261927] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602734.380430] eqos 2490000.ether_qos eth0: Link is Down
[602741.091340] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602742.202348] eqos 2490000.ether_qos eth0: Link is Down
[602748.977514] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602750.087238] eqos 2490000.ether_qos eth0: Link is Down
[602756.777160] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602757.888152] eqos 2490000.ether_qos eth0: Link is Down
[602764.912488] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602766.024603] eqos 2490000.ether_qos eth0: Link is Down
[602772.792277] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602773.909459] eqos 2490000.ether_qos eth0: Link is Down
[602780.598182] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602781.710408] eqos 2490000.ether_qos eth0: Link is Down
[602788.597128] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602789.721088] eqos 2490000.ether_qos eth0: Link is Down
[602796.453096] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602797.563982] eqos 2490000.ether_qos eth0: Link is Down
[602804.504462] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off
[602805.616574] eqos 2490000.ether_qos eth0: Link is Down

This clearly shows the device mode emulation being disconnected and the eth0 connection continuing to be unstable.

19

I think whatever you’ve done should not cause this, but obviously something in device mode is interacting with eth0. NVIDIA will probably need to reproduce this to find the cause. Can you provide the simplest steps to reproduce this?

20

Here are the steps to reproduce it

  1. Using the SDKManager, follow the on screen instructions and Flash the Xavier with latest Stable Release
  2. Disconnect the USB 3.0 Type.A to Type-C Cable
  3. Connect the LAN cable to the Xavier’s ethernet port

That’s all I have done. I’m starting to think this has more to do with hardware than software.