I need to be able to switch between two network configurations - an “office” one where I’m in the office and can access the company network (DCHP), and a “field” one where the the network interface is static. To do this I have two network interfaces files:
/etc/network/interfaces_office:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
#allow-hotplug eth0
# iface eth0 inet dhcp
/etc/network/interfaces_field:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.20.3.137
netmask 255.0.0.0
My /etc/network/interfaces file is then just a symlink that I can easily change to point to which file I’d like to use. This setup works fantastic on the TK1s that I have.
On my TX1 though, whenever I do this, eth0 doesn’t come up automatically on startup. I’ve disabled network manager (by creating a /etc/init/network-manager.override file that contains “manual”) to make sure it’s not interfering somehow.
When I connected to the serial port with an FTDI cable to monitor the start up the message RTNETLINK answers: Network is unreachable is displayed repeatedly until I manually start eth0 using sudo ifup eth0
Is there a reason eth0 won’t come up automatically?
I would really like to use the “allow-hotplug” option that’s commented out above instead of just “auto” so that booting the Jetson isn’t delayed if the network cable isn’t in. Again this works fine on the TK1s but I’ve commented it out to troubleshoot this issue on the TX1.
I’ve had similar issues, but never found a solid cause nor a solution. I’ve heard of other people having the issue on desktop and other x86_64 machines as well…and not just Ubuntu…perhaps it is just coincidence, but anything which has ever been touched by NetworkManager seems to have the possibility of this happening.
i had issues with eth0 at boot also, not identical to yours, but, one thing that helped me is having wireless enabled no matter if i was using it or not.
We’ve had similar issues with r23.2. We are not using network_manager. We’ve created our own udev rules and what we are seeing is that eth0 get’s two udev add events, and by one remove event (order doesn’t seem to be reliable). What we have done is the following:
Set /etc/network/interfaces.d/<whatever>
allow-hotplug eth0
iface eth0 inet dhcp
Note that we use allow-hotplug which means that eth0 isn’t brought up by upstart. This is so that upstart isn’t blocked waiting for dhcp (up to 60 seconds) during boot if network isn’t connected / active.
Create /etc/udev/rules.d/85-ifupdown.rules
# This file causes network devices to be brought up or down as a result
# of hardware being added or removed, including that which isn't ordinarily
# removable.
# See udev(7) for syntax.
SUBSYSTEM=="net", GOTO="net_start"
GOTO="net_end"
LABEL="net_start"
# Bring devices up and down only if they're marked auto.
# Use start-stop-daemon so we don't wait on dhcp
ACTION=="add", RUN+="/etc/udev/scripts/ifset.sh $env{INTERFACE} add"
ACTION=="remove", RUN+="/etc/udev/scripts/ifset.sh $env{INTERFACE} remove"
ACTION=="move", RUN+="/etc/udev/scripts/ifset.sh $env{INTERFACE} move"
LABEL="net_end"
Create /etc/udev/scripts/ifset.sh
#!/bin/bash
DEVICE=$1
ACTION=$2
/bin/echo "${ACTION} ${DEVICE}" >> /tmp/ifset.log
# NOTE(josh): udev jobs must be fast, we cannot call the command in this process. We need
# to attach it to another process group or it wont be allowed to finish. That is why we use
# 'at now' to run the ifup/ifdown command.
if [[ ${DEVICE} == "eth0" ]];
then
if [[ ${ACTION} == "add" ]];
then
CMD="/sbin/ifup --allow hotplug ${DEVICE}"
/bin/echo "${CMD}" >> /tmp/ifset.log
/bin/echo "${CMD}" | at now
fi
# NOTE(josh): eth0 is a "usb" device but is internal to the module, it cannot be
# removed, so we never shut this interface down, even if we get a "remove" event,
# which appears to be a spurious event pair (we get [add], [add], [remove] for eth0).
fi
Heres what we typically see in /tmp/ifset.log. Sometimes we see both add events for eth0 before the remove event. Sometimes it goes add, remove, add.
I had similar problems, and finally gave up on /etc/network/interfaces. I moved all network configuration to a script called from rc.local. Works reliably and no longer hangs at “Waiting for network configuration” at boot.
One thing I noticed that was odd–if I start pinging the board just before it starts to boot I get the message “Destination Host is Unreachable” as you would expect. Then part way through the boot sequence it starts responding to the pings and then it quits and you get the “Destination Host is Unreachable” message again.
So the interface is coming up, but then something is shutting it down.
I had seen similar behavior and attributed it to the fact that the udev “remove” event was being fired. Please note that if you utilize the script I posted you’ll need to install the “at” command. I added a note to my post above.
In my case the problem was that the file /var/run/dbus/pid is not removed when a forced shutdown is done, so when booting it can not crate that file and the dbus is not well initialized.
Modifing the /etc/init/dbus.conf to delete the file before executing the daemon did the work
# dbus - D-Bus system message bus
#
# The D-Bus system message bus allows system daemons and user applications
# to communicate.
description "D-Bus system message bus"
start on local-filesystems
stop on deconfiguring-networking
expect fork
respawn
pre-start script
if [ -f /var/run/dbus/pid ]
then
rm -f /var/run/dbus/pid
fi
mkdir -p /var/run/dbus
chown messagebus:messagebus /var/run/dbus
exec dbus-uuidgen --ensure
end script
exec dbus-daemon --system --fork
post-start exec kill -USR1 1
post-stop exec rm -f /var/run/dbus/pid