I have a TX2 in an Connecttech Astro carrier board running Ubuntu16.04 (L4T 28.1). The carrier has two Gigabit Ethernet ports which I would like to configure with static IPs. In system settings → network:
Wired Connection 1 ->IPv4 settings:
manual
IP:192.168.22.148
Mask: 24
Default Gateway: 192.168.22.1
Wired Connection 2 ->IPv4 settings:
manual
IP:192.168.1.148
Mask: 24
Under normal operation this TX2 is connected to another TX2 and some other components via a simple unmanaged switch. All components have static IPs set so they can operate without a dhcp server. When the TX2 is powered on everything works as it should but after 5 minutes, eth0 (wired connection 1) disappears. Looking at the syslog, it appears this is because dhclient doesn’t get a reply from a DHCP server (because there isn’t one connected) which triggers the interface to be shutdown. The avahi-daemon takes over eth0 and tries to configure it but fails.
I see the timeout in /etc/dhcp/dhclient.conf is set to 300 seconds.
I am trying to figure out why dhclient is doing anything since the interface is set to manual with a static IP.
I also configured the static IP via /etc/network/interfaces:
auto eth0
iface eth0 inet static
address 192.168.22.148
netmask 255.255.255.0
gateway 192.168.22.1
auto eth1
iface eth1 inet static
address 192.168.1.148
netmask 255.255.255.0
/etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq
[ifupdown]
managed=false
but this did not make a difference. So my question is why is dhclient making DHCP requests for eth0 when it’s configured as static? What’s the right way to fix this?
Couple other tidbits of information, 1) if a router or other dhcp server is attached, everything works perfectly. 2) I had a similar hardware configuration with a TX1 running Ubuntu 14.04 (L4T24.1) that worked fine.
This post is not helpful: networking - Why dhclient is still running when I choose static IP? - Ask Ubuntu.
NetworkManager can be quite annoying. It sounds like what you need is to remove management of eth0 while leaving WiFi managed. Then only remaining interfaces will change dynamically as things like WiFi go up or down (you’d just set it for static operation and NetworkManager won’t interfere). This may be of interest:
[url]http://xmodulo.com/disable-network-manager-linux.html[/url]
I disabled NM and that appears to have stopped eth0 from going down. However it seems to have another side effect of the SSH daemon not starting. It appears that when I connect a monitor/keyboard to the TX2 it starts up just fine, but if I don’t, whenever I try to SSH into the TX2, I just get a connect refused error. Any ideas on that?
Some services are tied to GUI login sessions. Perhaps sshd was somehow tied to this as well (it shouldn’t be, but if sshd is tied to a particular network route, then it won’t show up until that route shows up…and possibly NetworkManager still has its fingers in the mess). When there is no GUI login, and then again with GUI login, what do you see for:
sudo route
sudo systemctl status sshd.service
SO…it turns out there is this insidious script that runs on EVERY startup called /home/nvidia/report_ip_to_host.sh
Among things like trying apt-get install rsync and netcat EVERYTIME THE BOARD STARTS, one of the first things it does is
dhclient eth0
When that call fails (because the network its attached to doesn’t have/need a dhcp server) eth0 is shutdown and taken over by the avahi daemon.
re-enabling NetworkManager and disabling that script fixed the problem.
[rant]
I think what makes this aggravating is that on the TX1 this script existed in /home/ubuntu. On the TX2 it was moved to /home/nvidia (why was that user even added?). This script runs regardless if ubuntu or nvidia was logged in even though it wasn’t located in /home/ubuntu. As a TX1 user by default I used the ubuntu user. I knew this script existed in /home/ubuntu on the TX1 but where it didn’t exist in /home/ubuntu directory on the TX2 I assumed it didn’t exist on the TX2. I wish I could two and a half days of troubleshooting back. Arghhhh.
[/rant]
This was an interesting observation, since “report_ip_to_host.sh” is connected to another bug where installing packages with JetPack (and not just flashing) ends up deleting “/etc/rc.local” (it should only edit rc.local).
Failure to delete or edit rc.local apparently also causes IP address issues…this file should be run only once, but perhaps failure of JetPack to reach the Jetson after installing and thinking it is going to install packages not only fails to remove rc.local, but sets up a permanent run-on-start of this.
Is report_ip_to_host.sh found in your “/etc/rc.local” file? If so, then you’ve just discovered a new aspect to another JetPack bug…one which might explain some network strangeness for anyone who had an incomplete JetPack install (where flash worked, but the package install step did not complete…it would be a worse severity bug to re-run this script versus the severity of deleting rc.local…it would be better if the ip script were self-deleting and did not require JetPack to finish the job).
FYI, NetworkManager will still be annoying even without this bug.