When I boot up the TX1, despite being plugged into the router, it doesn’t grab an IP address and running dhclient eth0 simply hangs. The wlan0 interface does get an IP address and I can access the internet, but I’m unable to ssh in or even ping that IP address from my other machines on the same network. FWIW, my Ubuntu host machine and Mac laptop are both connected to the router and get IP addresses just fine and ssh/ping isn’t an issue.
Any thoughts or suggestions?
Thanks!
I would first go here and see if the firmware is an issue:
https://devtalk.nvidia.com/default/topic/901180/jetson-tx1/my-jetson-tx1-is-not-able-to-connect-to-wifi/
As long as the TX1 is not churning away with high CPU use, this probably is not the issue…but this is probably the first step in verifying what the issue is.
You might also want to disable WiFi first, and then reboot and see if eth0 still behaves the same way when wireless is not interacting (WiFi setup could complicate things even when working as expected).
OK, thanks for your response. The CPU is not under heavy load and I’m able to run “sudo iw dev wlan0 scan” and get a valid response.
When I disable wifi and reboot, the TX1 times out while attempting to setup the network.
One thing I notice is that when the cable is plugged in, the ethernet port doesn’t have any link lights, despite the cable/connection working for my laptop. Anyhow, below is some debugging output in case it helps.
ubuntu@tegra-ubuntu:~$ sudo lshw -C network
*-network:0
description: Ethernet interface
physical id: 1
logical name: eth0
serial: 00:04:4b:58:05:14
capacity: 1Gbit/s
capabilities: ethernet physical mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v2.03.3 (2015/01/29) duplex=half link=no multicast=yes port=MII
ubuntu@tegra-ubuntu:~$ dmesg | grep eth0
[ 21.197282] cdc_ether 2-1:2.0 eth0: register 'cdc_ether' at usb-tegra-xhci-1, CDC Ethernet Device, 00:04:4b:58:05:14
[ 21.201685] cdc_ether 2-1:2.0 eth0: unregister 'cdc_ether' usb-tegra-xhci-1, CDC Ethernet Device
[ 21.439160] r8152 2-1:1.0 eth0: v2.03.3 (2015/01/29)
[ 21.439169] r8152 2-1:1.0 eth0: This product is covered by one or more of the following patents:
[ 21.629841] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 806.603426] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
ubuntu@tegra-ubuntu:~$ nm-tool eth0
NetworkManager Tool
State: connected (global)
- Device: eth0 -----------------------------------------------------------------
Type: Wired
Driver: r8152
State: unavailable
Default: no
HW Address: 00:04:4B:58:05:14
Capabilities:
Carrier Detect: yes
Wired Properties
Carrier: off
ubuntu@tegra-ubuntu:~$ cat /var/log/syslog | grep eth0 | tail -n 22
Jan 19 22:02:50 tegra-ubuntu kernel: [ 21.629841] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 19 22:15:56 tegra-ubuntu NetworkManager[762]: <info> (eth0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36]
Jan 19 22:15:56 tegra-ubuntu NetworkManager[762]: <info> (eth0): cleaning up...
Jan 19 22:15:56 tegra-ubuntu NetworkManager[762]: <info> (eth0): taking down device.
Jan 19 22:15:56 tegra-ubuntu NetworkManager[2389]: SCPlugin-Ifupdown: devices added (path: /sys/devices/platform/tegra-xhci/usb2/2-1/2-1:1.0/net/eth0, iface: eth0)
Jan 19 22:15:56 tegra-ubuntu NetworkManager[2389]: SCPlugin-Ifupdown: device added (path: /sys/devices/platform/tegra-xhci/usb2/2-1/2-1:1.0/net/eth0, iface: eth0): no ifupdown configuration found.
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): carrier is OFF
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): new Ethernet device (driver: 'r8152' ifindex: 9)
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): bringing up device.
Jan 19 22:15:57 tegra-ubuntu kernel: [ 806.603426] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): preparing device.
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> (eth0): deactivating device (reason 'managed') [2]
Jan 19 22:15:57 tegra-ubuntu NetworkManager[2389]: <info> Added default wired connection 'Wired connection 1' for /sys/devices/platform/tegra-xhci/usb2/2-1/2-1:1.0/net/eth0
Jan 19 22:16:22 tegra-ubuntu dhclient: Listening on LPF/eth0/00:04:4b:58:05:14
Jan 19 22:16:22 tegra-ubuntu dhclient: Sending on LPF/eth0/00:04:4b:58:05:14
Jan 19 22:16:22 tegra-ubuntu dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x77e4c8ba)
Jan 19 22:16:25 tegra-ubuntu dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x77e4c8ba)
Jan 19 22:16:31 tegra-ubuntu dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x77e4c8ba)
Jan 19 22:16:40 tegra-ubuntu dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 (xid=0x77e4c8ba)
Jan 19 22:16:50 tegra-ubuntu dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x77e4c8ba)
The lack of link light, combined with lshw “link=no”, on an otherwise working network cable, is suspicious of a bent pin (or other hardware defect). Can you look very closely at the pins and see if they look to be correct? Also, look closely at the circuit board side of the connector…I’m not sure what you would see, but there may be something suspicious like lifted or bridged solder.
I’m not sure what to make of the syslog content, NetworkManager seems to complicate things since it may be mixed with other conflicting configuration. The multiple DHCPDISCOVER though seems odd, it should have had an answer on the first attempt. If the cable is working correctly, then there might be setup required in the router…but the cable issue seems to be higher on the list of possible causes.
Not sure if this is related, but anyway here’s the problem I’ve experienced and how I work around it.
We have 2 Jetson TX1 boards in the lab. When we first flashed JetPack 2.0 onto the boards, both worked fine. However, after certain automatic software updates from Ubuntu, eth0 just stopped working on both boards with no link light.
I’m able to fix the problem manually every time by:
sudo ifup eth0
sudo dhclient eth0
However, I wonder whether the Ubuntu updates messed up certain configuration in TX1’s rootfs…
Hello jkjung, I do not see any issues after performing an apt-get update/upgrade on my Jetson TX1, which was installed via JetPack 2.0. This issue also does not seem to be widespread. Were there any networking components that were modified on your system outside of the packaging system?
Another possibility is that a previous package upgrade may have introduced a regression that may or may not be fixed in a newer update. Looking through the apt history logs from /var/log/apt/ might help figure out which package may have introduced this if you know when the Ethernet ports stopped working.
I would be curious to see if this happens with a new JetPack 2.0 installation and an upgrade.
my eth0 on tx1 has also become problematic since install about 3 weeks ago. at first eth0 worked at every boot and now it has become one out of every 3 or 4 boots. i have been through all hardware inspections i can think of and got a new cat5 cable. when it does not work it just is not initialized, it seems. i also suspect something software wise got borked and was doing a search before i posted the question of is it possible to re-installed a nvidia specific eth package and if so where do i download it? my wi-fi is ok although slower so if the lan does not start i can use wi-fi but that does not address nor fix the issue. i’d appreciate being able to have eth0 as an option every boot, as it was. i’m getting tired of flash again when there are issues as i have done that twice before.
@dkryder: In every case similar to what you describe (including for desktop computers) the first thing I suspect is the router. Routers are notorious for this unreliable behavior, including becoming too slow to respond in time for DHCP requests after they’ve run a while. See if rebooting your router changes anything…which is about as simple and pain free as it gets compared to other tests.
Most routers (including a Linux desktop host used as a router) have logs one can watch as a remote system tries to boot up and run a DHCP request. Desktops somewhere in “/var/log/” (or dmesg), router appliances via a web interface. If rebooting the router does not help, see if you can gain access to router logs and determine if a DHCP request ever made it to the router.
linuxdev, thing is, the router works fine for 5 other devices [2 on ethernet/3 wi-fi] and with the tx1 when using wi-fi. but i agree there could be an issue so i will check that. i’m just going through a process and in the system log there is continual reference to nss-myhostname not being installed. did some poking around and read that nss-myhostname is an alias of sorts but to check the hosts file and it shows tegra-ubuntu as 127.0.1.1 & localhost as 127.0.0.1. it was suggested that perhaps both entries should be 127.0.0.1 any insights? thanks.
Maybe you have a hostname collision on your network, or one of the Ubuntu updates made an unwanted change to your network configuration?
FYI, there are no nVidia-specific files for networking. The Realtek drivers are mainstream kernel, network setup is mainstream Ubuntu. So far as router issues go, caching is why they fail on some ports but not others…no matter how many devices the router works with, cache has a bad tendency to get in the way on routers that are never rebooted. In the original case of this thread there was also a link failure, which is indicative of physical connection (beyond software). Does your link light fail to go on when network fails?
It is possible for some of the network setup from JetPack to be incorrect, but JetPack uses standard Ubuntu interfaces for this. JetPack may not be aware of any special setup required, e.g., firewall configurations or other custom authentication (e.g., SSL/TLS certs).
NSS is related to anything looking up “names” (network, password, etc). This could cause an issue, but dotted-decimal addresses should show up for ping and ssh when requests use a dotted-decimal address (the “x.x.x.x” format, as opposed to a name). Having 127.0.1.1 and 127.0.0.1 is correct for local host loopback, but having nothing pointed at your outside network is an issue…none of the 127.x.x.x addresses are remote host. The loopback will be associated with interface “lo”, while a real ethernet will be listed as something like “em0”, “eth0”, so on (via ifconfig).
Routers generally clear cache via reboot. Caches have complicated rules for re-use and clear. Limited memory means caches can fill up even with small numbers of DHCP users. Again, this is almost always fixed by reboot since cache memory is all cleared.
i’m able to restart the eth0 using this
sudo service network-manager restart
which gives me my ethernet back.
a bit of reading suggests that /etc/network/interfaces plays a role in bring up the eth0 at boot. that file is blank except for a reference to a source directory which also happens to be empty.
linuxdev, thanks for that information that there are no network aspects specific to nvidia, i was hesitant to make adjustments prior to knowing this.
i am thinking now that there is some entry in some file which is necessary to bring up eth0 at boot. a stumbling block is that many tips from search do not mention the build or if a desktop unit as it seems that desktop installs are different as well as some fixes work for ubuntu 12 and below while others above and i read that 14.04 has some of its own. this is all new to me as i never dropped down into understanding how ubuntu is different before. actually, i think my install does bring up eth0 but for some reason stops it.
Today 04:10:57 PM tegra-ubuntu NetworkManager[787] <info> (eth0): new Ethernet device (driver: 'r8152' ifindex: 9)
Today 04:10:57 PM tegra-ubuntu NetworkManager[787] <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Today 04:10:57 PM tegra-ubuntu NetworkManager[787] <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Today 04:10:57 PM tegra-ubuntu NetworkManager[787] <info> (eth0): bringing up device.
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] <info> (eth0): preparing device.
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] <info> (eth0): deactivating device (reason 'managed') [2]
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] SCPlugin-Ifupdown: devices added (path: /sys/devices/platform/tegra-xhci/usb2/2-1/2-1:1.0/net/eth0, iface: eth0)
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] SCPlugin-Ifupdown: device added (path: /sys/devices/platform/tegra-xhci/usb2/2-1/2-1:1.0/net/eth0, iface: eth0): no ifupdown configuration found.
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] <info> (eth0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36]
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] <info> (eth0): cleaning up...
Today 04:10:58 PM tegra-ubuntu NetworkManager[787] <info> (eth0): taking down device.
and
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): new Ethernet device (driver: 'r8152' ifindex: 9)
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): bringing up device.
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): preparing device.
Today 04:12:16 PM tegra-ubuntu NetworkManager[2268] <info> (eth0): deactivating device (reason 'managed') [2]
a few pastes from syslog.
One thing which always gets in the way for me is that older networking and NetworkManager packages are mixed. I get the feeling that NetworkManager is “newer” and intended to deal with things like WiFi which connects and disconnects, and needs a dynamic control depending on conditions. Every time NetworkManager gets involved it seems to give wired networking a headache (or the admin gets a headache). The result can be that wired networking gets updated, altered, added or removed depending on what WiFi does…unless configured exactly correct. I’ve never quite figured out exactly what “correct” is on a hybrid system. This hybrid mix is probably why some of those files are empty. If you google for information, you may be interested in adding to your search regarding how you want wired to behave as wireless changes.
it seems that out of the box this ubuntu install is the ultimate build in configuration options, it starts with much just blank, no assumptions here. i suppose i should be happy that it gives me what it does. be much nicer if i could just place the mouse against my forehead and run a configuration extraction program to make all option choices automagically.
edit: i have found that my selection to disable wifi in system settings was interfering with the boot setup of eth0. i have no idea why this should happen but for me going to system settings and enabling wifi ended [well, for the past couple days] my eth0 problems. i simply let it boot wifi/eth0 and then deselect wifi if i do not want this device on wifi.