I would use device bonding, meaning you are creating a new virtual device for which you assign the network settings (e.g. IP address, mask, etc.) and then you enslave both the ethernet and wifi interfaces to that interface.
Something like:
$ sudo modprobe bonding
$ sudo ifconfig bond0 192.168.0.1 netmask 255.255.0.0
$ sudo ifenslave bond0 eth0 wlan0
This has the advantage of covering all your scenarios from 1 to 5 with one exception: you have only 1 IP address. If that would be a problem, then you could always create an "alias" (e.g. bond0:0) and give a different IP address for that one. Then you would always have both IP addresses reachable even if only 1 interface is active.
More details can be found online. E.g.: http://www.codekoala.com/posts/bonding-eth0-and-wlan0-arch-linux/
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
The link given by @steve is appropriate, but if you want to try something simple first just to see what the device does you can use
dnsmasq
, which is a simple dns and dhcp server. Install withsudo apt-get install dnsmasq
. If this also enables and starts the server you need to stop and disable it.If, say, your device is on your ethernet interface
eth2
, and you have donesudo ifconfig eth2 192.168.9.1
to set the interface ip address, then you can try:which sets up a dhcp server in debug mode (-d), not as a daemon, with dns (port=0) able to offer addresses in the range .2 to .10, and to hold the same ones for 99hours.
If your device broadcasts a request to discover an address you should see it, and the reply (offer):
The numbers are the ip address assigned and the device's mac address. You may need to reset or power on the device if it has given up broadcasting. The device might reply to
ping 192.168.9.2
and then you can try to ssh too. You can interrupt the dnsmasq once the address has been offered in this test and put the options in the standard dnsmasq config file and so on.You may also usefully run
sudo tcpdump -i eth2
to see what packets pass.