I have flashed the Xavier using the SDK Manger from a Linux host computer (I was unable to install the additional SDK components, but that’s another issue) and when I went to use it independently from the computer it will not connect to the internet. I plug in the exact same Ethernet cord that I use for other devices and the Xavier does not connect to the internet! I have tried connecting via another computer and still nothing. The Xavier will recognize the Ethernet cord and show it in “Connection Information” so I am unsure why it won’t connect. Help please.
What do you see from the commands “ifconfig”, “route”, and “dmesg | grep -i dhcp”? Does the ethernet go to an ordinary router appliance, and if so, is the router set up to work only with specific MAC addresses?
Thanks for the reply!
I don’t believe the Ethernet router is set up to work with only specific MAC addresses because it worked for an out of the box Jetson Nano without any extra configuration.
these are the outputs:
Ifconfig
etho0: flags=4168<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.216.0.19 netmask 255.255.255.0 broadcast 10.216.0.255
inet6 fe80::995:3638:9bb2:a212 prefixlen 64 scopeid 0x20<linkL
ether 00:04:4b:cb:94:d6 txqueuelen 1000 (Ethernet)
RX packets 10564 bytes 565189 (565.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 554 bytes 45148 (45.1 KB)
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::dc84:3ff:fe84:6f35 prefixlen 64 scopeid 0x20<link>
inet6 fe80::1 prefixlen 128 scopeid 0x20<link>
ether b6:1b:d1:8b:a4:05 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 888 (888.0 B)
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 555 bytes 45535 (45.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 555 bytes 45535 (45.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b6:1b:d1:8b:a4:05 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 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b6:1b:d1:8b:a4:07 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 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
Kernal IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 20100 0 0 eth0
default _gateway 0.0.0.0 UG 32766 0 0 l4tbr0
10.216.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 l4tbr0
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 l4tbr0
dmesg | grep –i dhcp
Empty
whereis dhcp
dhcp: /etc/dhcp
ifconfig indicates there is a valid address, 10.216.0.19 (with a “/24” subnet mask). This means the port is up and that DHCP worked between the Jetson and the router.
You have two gateways (only used if you access an address outside of the 10.216.0.19/24). The one with the lower metric is used first if it is available, and switches over to the higher metric if the lower metric goes down (there may be some timeout period before there is recognition of a failed route). The gateways:
default _gateway 0.0.0.0 UG 20100 0 0 eth0
default _gateway 0.0.0.0 UG 32766 0 0 l4tbr0
Thus the eth0 is the first device for access outside of the 10.216.0.19/24 subnet, and is as expected. This should be good. The bridge is just a route to the USB virtual ethernet. This would fail if either the type-C USB is not connected, or if the host PC the type-C cable talks to is not set up to forward. Normally this should not be an issue, but it is possible that the metric may change depending on whether the USB-C virtual ethernet is plugged in or not (NetworkManager can do unexpected things as one route or another is detected as changing).
The question of where DHCP is was just one of asking what device is being a router, e.g., an appliance or the PC over virtual USB-ethernet (and an address is assigned so the router is working and the Xavier is talking to the router). In this case we can say with confidence that the issue isn’t within the Xavier if those outputs from ifconfig and route were valid during a time when networking failed. If not, then we are missing some detail.
In case those command logs were during a failed situation, then we can be certain that the failure was actually from outside of the Jetson. Two things stand out as a next test:
- What happens if you use DNS? Example to see if popular domains are visible:
host nvidia.com host google.com - Traceroute will indicate where a route fails or succeeds (but only if ICMP is enabled on the hop...some hops will not reply, but hops further down the stream would still replay if they enable ICMP). Examples to test if the "host" command worked (this won't work if "host" failed):
traceroute nvidia.com traceroute google.com
Does DNS (host) work? If DNS worked, how far do the traceroute commands work at the furthest node?
1 Like
You mentioned “The bridge is just a route to the USB virtual ethernet. This would fail if either the type-C USB is not connected, or if the host PC the type-C cable talks to is not set up to forward.” However, I am not connected to a host computer to access internet, I am simply connecting the ethernet cord straight to the Xavier. Should I be connecting to internet via the host?
These were the outputs from testing the DNS via host commands:
host nvidia.com
nvidia.com has address 216.228.121.209
nvidia.com mail is handled by 10 nvidiahk.nvidia.com.
nvidia.com mail is handled by 10 hqemgate09.nvidia.com.
nvidia.com mail is handled by 10 hqemgate07.nvidia.com.
nvidia.com mail is handled by 10 hqemgate10.nvidia.com.
nvidia.com mail is handled by 10 hqemgate08.nvidia.com.
host google
google.com has address 172.217.164.238
google.com has IV6 address 2607:f8b0:400b:801::200e
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
However, the traceroute command returned an error that I actually don’t have the command traceroute. Does this indicate that I am missing something on the device for functionality?
traceroute nvidia.com
bash: traceroute: command not found
You are ok not going to the host and not using the USB-C virtual ethernet. The “metric” on the “route” command shows a lower cost to use eth0 than to use the bridge. Thus eth0 is the active route. If something were to cause eth0 to go down, then the bridge over USB-C virtual ethernet would be next to try since it is the next more costly route metric. This is all fine, and as is, you can ignore the USB-C virtual ethernet and the bridge to it.
For traceroute install:
sudo apt-get install traceroute
The host command says your ethernet is working. At least along the route which goes to the DNS lookup. This might be performed in part by the router, but essentially this guarantees eth0 is up and working (at least up to the router…this is the only part the Xavier has control of). “traceroute” will check issues external to your Xavier. Whatever is going on looks to be external to the Xavier.
Unfortunately, the install command for traceroute does not appear to be working, It says that it is unable to locate the package.
Interesting. That should be a standard package and not require any sort of special configuration to find. Are you behind a proxy or firewall?
If DNS works, then talking to the internet “works.”
You could try pinging a known IP address, like 8.8.4.4 (google DNS) or 1.1.1.1 (cloudflare DNS.)
/usr/sbin/traceroute is actually managed by alternatives, it’s provided typically by /usr/bin/traceroute-nanog from the “traceroute” package (at least on “bionic” version of Ubuntu, which jetpack is based on.)
However, this works perfectly fine on my jetson:
sudo apt install traceroute/bionic
So you should be able to tget traceroute that way … if you’re connected to the internet.
Who manages your DHCP server? Is this in an office or in a home?
How much else do you know about your network environment? What is your default gateway address?
If it’s not 10.216.0.1 then the configuration you have won’t work.
Try reaching that address with “ping 10.216.0.1”
@linuxdev I am behind a firewall (I believe)
@snarky I have tried to install traceroute and it does not find it
However, I am connected to internet now, I was able to share the wifi network from another computer and then use an ethernet cord to connect the two by following this website: How to Share your Computers WiFi with other Ethernet Devices
(I don’t know why this worked this time, as I tried this earlier to no avail)
Thank you both for your help!! :)
1 Like