You can use a bridge interface. You can use brctl
from bridge-utils to create a bridge interface. For example,
$ brctl addbr br0
$ brctl addif br0 eth0 eth1
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00004c9f0bd2 no eth0
eth1
So after adding interfaces eth0
& eth1
into the bridge device br0
you're left with the following setup. You can use ifconfig
to see it:
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr BC:AE:AA:34:22:11
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr BC:AE:AA:34:11:22
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...
And the bridge device with the IP address:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr BC:AE:C5:11:22:33
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
...
You mention a) other people being involved, b) simple linux installs. I would give the following tip: make a point of installing the package for avahi-daemon.
Also set a descriptive hostname. With MDNS, you don't need to guarantee the hostname is unique. In fact the MDNS spec says you're not "supposed" to make it unique by appending a random number or a large ID like a MAC address; this is considered to put off users for no good reason. sensor5
would be reasonable though. The protocol automatically resolves conflicts by appending sequence numbers (with a dash) to the MDNS hostname.
Alternatively, if you're going to use Samba to download the data files, you could check that legacy IPv4 discovery using NMBD (netbios over TCP) is functioning. The system should show up in smbtree -N
. NMB does not tend to resolve naming conflicts. People generating hostnames automatically tend to append the last few characters of the MAC address, to avoid this problem.
The advantage of having a discovery protocol like MDNS (avahi-daemon) enabled, is it provides a reliable way to discover the IP address even when someone has configured it statically.
- For simplicity, disable other (wireless) net connections on your laptop.
tcpdump -n
/ wireshark / tshark. I.e. listen on all interfaces. If you listen on a specific interface, it will probably stop/refuse to run when NetworkManager sees the cable unplugged.
- Plug laptop in to device.
- If device does not respond (software does not respond to link change), simply power-cycle the device.
Step 2 will also reveal when the device is configured as a DHCP client. (You could start a DHCP server then). The packet capture would also confirm the IP address assignment.
Alternatively, the device can be plugged into a network (presumably providing a DHCP server, at least for the benefit of your laptop). The discovery protocol & addresses will be visible in packet captures, provided you're connected to the same network, and either it is a basic network switch with no multicast filtering enabled, or you are running the specific discovery protocol. I believe any current consumer ethernet switch will work (including the wired ethernet switch built in to a consumer router).
If some devices are expected to be connected to networks, you should attach a label with their hostname. (If it has a static IP, this also definitely wants to be labelled).
Isn't it nice how this can work for different discovery protocols? Consumer network devices will always run some sort of discover protocol, and so this technique is known (or discoverable using Google) by many "power users". However if you start from a minimal embedded linux install, then you might not have any discover protocol enabled by default.
The other most significant discovery protocols are LLMNR (Windows, systemd-resolved), LLDP (enterprise routers, IP phones and others) and SSDP for UPnP devices including consumer routers. That's the great thing about standards....
Best Answer
If you specify
instead of
in
/etc/network/interfaces
, then the connection will only be initiated byudev
when something triggers it, instead of at every boot.That might be sufficient to handle your case, but not necessarily; the
interfaces
manpage mentions thatYou might need to use
/etc/network/if-up.d/00check-network-cable
from theifupdown-extra
package to skip the interface if no cable is connected.