Ethernet Port not working: Connection Light on switch doesn't turn on.

Greetings,

I just bought an Nvidia Jetson AGX Xavier, and it arrived a few days ago. I successfully installed JetPack 4.1.1 with the other included packages (Cuda, opencv, etc.) using the connection via USB-c through the host option (running the host in Ubuntu 16.04).

After booting, the Ethernet port does not seem to detect any connections at all. I rebooted the access point and tested the connection with another device using the same port and Ethernet cable, and it works perfectly with that other device. The switch even has an light indicator which turns on when a device is connected, and it turns on with the test device I used; however, it fails to do so with the Nvidia Jetson AGX Xavier.

I even tried out all the solutions discussed in this forum with no success. I also tried to reflash the device but now using the connection through the Ethernet cable option for the other included packages, and, as expected, it can only install the OS but not the other packages (because the OS is installed though the USB-c connection).

I followed anti ESD precautions during the whole process. Is this a possible manufacturing error?

You may flash OS through microUSB2 port, on the left (near finger) in this picture while the USB3.1 type C is on the right side.
Which one did you use ?

[EDIT: Sorry for weird advice…The microUSB port on the left is for serial console]

Additional question: Does the unit boot to where you can log in locally, and if so, can you see the output of “ifconfig”?

H. First of all, thank you for the responses.

I’m flashing it though the USB3.1 type C port (the one on the right side of the picture) as the flashing tutorial indicates. After all, I’m happy that it does in fact get correctly flashed, and I can login into the “nvidia” account successfully.

“ifconfig” shows the following when connected to the AP:

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:04:4b:cb:a2:28  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
        device interrupt 40  

l4tbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.55.1  netmask 255.255.255.0  broadcast 192.168.55.255
        inet6 fe80::6c35:13ff:fef5:568d  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::1  prefixlen 128  scopeid 0x20<link>
        ether 3a:5e:55:8f:c6:52  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 1788 (1.7 KB)
        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 717  bytes 45323 (45.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 717  bytes 45323 (45.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 3a:5e:55:8f:c6:52  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

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 72:18:8f:5e:47:83  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

Hope this helps and thank you for the support.

Looks like the only issue is that the ethernet port did not get an address assigned…a function of the router. Are you using a router appliance, or did you select host to act as router?

I’m connecting it to a modem (which usually serves as switch, router, AP, etc. all in one in a house). DHCP is running correctly on the modem, and the Xavier is configured to use it as well. The modem’s model is “ZNID-GPON-2426A-0AX”.

What I’m concerned about is that when I connect the Xavier to the modem, the modem’s LED indicator doesn’t turn on. The thing is that, if I connect another computer, it always turns on regardless of the state of “ifconfig”. When I connect another computer to the same port on the modem using the same cable, the LED indicator is turned green even if I set the Ethernet interface as “DOWN”. This tells me that the LED indicator is probably only indicating a physical connection and not an established connection on software.

You might have to install ethtool (“sudo apt-get install ethtool”), but what do you see from:

sudo ethtool eth0
sudo ethtool --phy-statistics eth0

I don’t know what the modem LEDs should show, but sometimes they depend on speed or other settings. A failure to reach the modem would cause a DHCP failure though. I do see in your original ifconfig that no packets were seen, and this too would match…but a router set to only respond to known MAC addresses would also have that effect (the LED tends to point at something else though).

Thank you again for the response. I had to install ethtool using an USB with the .tar.gz (because of the lack of Internet). Here are the results from running such commands:

nvidia@jetson-0423418010502:~/Desktop/ethtool-4.19$ sudo ethtool eth0 
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: d
	Link detected: no
nvidia@jetson-0423418010502:~/Desktop/ethtool-4.19$ sudo ethtool --phy-statistics eth0 
PHY statistics:
     phy_receive_errors_copper: 0
     phy_idle_errors: 0

I hope this helps. More notes on the modem: It’s not configured to whitelist or to blacklist MAC addresses (e.g. I had never connected my laptop before, but the Ethernet connection worked nevertheless). Any suggestions?

According to this the ethernet is correctly advertising its ability to work with a large range of settings. Additionally, the PHY (which is the physical interface directly touching the copper) is working without error. I suppose a cut wire might also show as working without error…meaning perhaps if there is no traffic there wouldn’t be an error…that instead the cut wire would be an undetectable error. So this doesn’t mean something isn’t wrong, but it does mean so far as the software on the Xavier can be used for debugging “all is working well”.

Does your router have any option to tell you which MAC addresses it sees, or does it have any kind of logging? It really looks like the router simply isn’t responding. Network devices have been known to die for various reasons, but usually if some part of hardware is damaged then software will generate errors in logs. I am curious, since your MAC is “00:04:4b:cb:a2:28”, what do you see from:

dmesg | egrep -i "0.*4.*4b.*cb.*a2.*28"

…are there any errors related to this?

Thank you again for the response. After running dmesg, I get the following:

nvidia@jetson-0423418010502:~$ dmesg | egrep -i "0.*4.*4b.*cb.*a2.*28"
[    4.402423] eqos 2490000.ether_qos: Setting local MAC: 0 4 4b cb a2 28

I’ll have to look as well on the modem to see if it has the functionalities you mentioned. For that, I’d need to ask for the device password (from my landlord) to take a look. In the meantime, I’ll try two things and let you know how it goes: 1. trying to connect it to a public connection at my uni (it accepts any device that’s connected to the Ethernet cable anyways) 2. I’ll test a PCIe card with an Ethernet port at both locations (my apt and my uni).

Basically your log does show MAC is ok, and MAC is how DHCP will identify a given connection.

Just a comment ahead of time: If you don’t control the router, and if multiple computers you don’t control are inside the LAN, then you should immediately change the password of “ubuntu” and “nvidia” users…these are standardized passwords everyone in the world knows. Universities are famous for how fast automated cracking type software will reach a new device.

Sometimes a router has issues with cache. In a case where one ethernet was used on a port, and then another switches, a failure to update the cache might cause a failure to get your DHCP request filled. If you controlled the router I’d just say to reset it. In the case that you don’t own this, ask the landlord if the MAC address shows up (and I hope he knows what a MAC address is and how to check the logs…if not it might be a long day figuring it out). Trying an alternate computer device on that port would also be of use in testing.

Ok, so coming back to you. I tested it in another router, and, on this one, I had access to the configuration panel. So I did the following:

  1. I made sure that there were no white-listed or black-listed MAC addresses.
  2. Tested a port with my laptop, and checked that there was an established connection. This was confirmed by checking ifconfig and noticing that the interface had an IP, checking that the LED indicator was on, and looking for the MAC address in the router logs. All of the last three things happened.
  3. Proceeded to connect the Xavier with the same new router, on the same port, using the same cable. Neither the LED was turned on, nor did ifconfig showed a connection, nor the router logs showed any connection attempt coming from the Xavier.

Additionally, I just bought a PCIe with Ethernet. After doing all the steps I mentioned before, I connected the PCIe with Ethernet to the Xavier, and tested the connection. Good/Bad news: the connection was successful. Now my Xavier is even connecting to the Internet, but It’s doing so through the PICe card I bought and not through the original Ethernet port:

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.11  netmask 255.255.255.0  broadcast 192.168.15.255
        inet6 fe80::b099:17b9:a79d:9fb2  prefixlen 64  scopeid 0x20<link>
        ether 50:3e:aa:06:74:0a  txqueuelen 1000  (Ethernet)
        RX packets 167992  bytes 246988698 (246.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38973  bytes 3120570 (3.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 76  base 0xd000

Note: I even tested it with the old router (the one in my apartment; the one we were trying to connect the Xavier with in the first place), and it worked (via the PCIe Ethernet card).

I think we can conclude that the Xavier’s original Ethernet port had a manufacturing error (possibly a bad soldering or miss-connection after the Network card). Do you agree? If so, how can I apply a guarantee to get a Xavier with no manufacturing errors?

It sounds like it is time to RMA. Lots of things can get in the way of networking, but your specific testing indicates the fault is with the Xavier. It does sound like a wire is open, e.g., via cold solder joint, or maybe just a bent pin inside the connector.

I don’t think it is possible to ever guarantee a unit without error unless you go to some MIL spec high reliability type unit. This is the first Xavier I’ve heard of with this issue. However, if you go here you can find some information on near the top on RMA (just search for “RMA”):
[url]https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/[/url]

Thank you for the recommendations. I just noticed we sent a message roughly at the same time. Do not worry… it’s not connected to the University network: I brought the new router to my apartment (it’s not dorms), and the modem in my apt is only used by me (each apt has it’s own with and has a different password). However, I do agree that changing the default password is a must, so I just changed it. Anyways, I’m not using the Xavier for nothing other than the quick tests we talked about (for which I never got a connection until now that I have the PCIe with Ethernet).

With regard to the cache: I tried both resetting it and without resetting it, and I still get the same results.

Thank you so much for the support. Hope you have a great week. It’s frustrating sometimes, but things happen. Let’s see how it goes with RMA.

I have exactly the same problem…I thought it was just a configuration problem. It seems that it is not…

I had this problem as well, and was thinking that I needed to RMA my Xavier, but then thought about this other l4tbr0 device that I was able to get a network connection from:

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>
        inet6 fe80::14d9:27ff:fe95:405c  prefixlen 64  scopeid 0x20<link>
        ether 26:f8:e5:be:23:b5  txqueuelen 1000  (Ethernet)
        RX packets 617271  bytes 923939989 (923.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 60515  bytes 3709485 (3.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Apparently this is a network interface used as the device endpoint of a point-to-point connection with the host system over the USB flashing cable (USB A to C cable plugged into the “front” of the Xavier). It seems this interface interferes with the built-in ethernet cable as after I unplugged this flashing cable and rebooted the device, the built-in ethernet port started working.

Hello
I have exactly the same problem. I have received four units within the RMA system and the same issue appears in the four.
I am getting tired, come on!!! From NVIDIA have sent four different units!!! This must be a software problem,
Nobody can figure out a possible explanation??