Linux – Simple method to reliably connect 2 machines via ethernet cable

dhcplinuxnetworking

I would like to connect 2 machines via Ethernet cable reliably. One machine called active (my laptop), the other machine is called passive (not internet connected,just sits and collects data from its survey interface). The method that I imagine might work is:

  1. Set up my laptop to provide IP addresses to others via DHCP
    (dnsmasq?)
  2. Passive machine is a simple linux installation –
    by default they are ready to connect via Ethernet and acquire
    address vie DHCP
  3. I go with my laptop to the machine I need to
    collect data from and just plug in the Ethernet cable to connect the
    two. DHCP server is set up to provide one address only, therefore I
    always can access the passive machine through the same address from the active machine.

Depending whether the network cards can detect crossover, I use either crossover cable or normal.

I am thinking of a scenario when the laptop is easy to reconfigure but the passive machines might be many (but connection to them only to one at a time) and possibly they would not be configured with the same IP. Then providing them with DHCP address might be a solution that "just works" that would avoid reliance on there being a certain IP configured statically.

Could you provide me with tips/caveats as to if this would work or not?

Best Answer

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.

  1. For simplicity, disable other (wireless) net connections on your laptop.
  2. 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.
  3. Plug laptop in to device.
  4. 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....

Related Question