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?

  • 6
    If the configuration is this simple, why don't you just configure static addresses on both machines? Feb 15 '17 at 8:55
  • 1
    As @JohanMyréen says, DHCP is a huge overkill for this situation, just use static addresses. And make sure to get a crossover cable if you don't have a switch. That's about all there is to it. Feb 15 '17 at 9:09
  • No if there are multiple passive machines
    – r0berts
    Feb 15 '17 at 9:12
  • @r0berts even with multiple passive machines — if they're never connected simultaneously, you can set them up with the same static IP address. Feb 15 '17 at 9:16
  • 2
    If you go for the dhcp server alternative, make sure the dhcp server only listens to the interface you intend to connect the passive machine to, if this interface is not the only one on the active machine. Otherwise you may mess up things with two competing dhcp servers on the network. Feb 15 '17 at 10:00

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....

  • Thanks, that is great with very specific and useful comments. I will also look into avahi, but in my case it might suffice with just knowing IP address. Limesurvey luckily supports JSON-RPC interface and R has a module limer on github (I tested it already on VM) - so as soon as IP connection is up and I know the devices address, I can gather data via http directly from R. But I now feel encouraged to explore the connectivity with wireshark, which is very interesting.
    – r0berts
    Feb 15 '17 at 13:49
  • I'm trying to make the point, that if someone configured or reconfigured one of these linux installs with a static IP (maybe they label the device, but the label falls off or something) - and avahi is not installed - it's possible the device will not generate ANY packets, even during boot. For Linux installs, I advocate making sure that Avahi is running, as a preventative measure. That said, it's also possible you'd see packets if it tries to set its clock using an NTP server.
    – sourcejedi
    Feb 15 '17 at 14:07
  • Thanks, this is very good to know I will check avahi is installed
    – r0berts
    Feb 15 '17 at 14:08

I agree, static IP would be the better way to go for a direct machine-to-machine system. Use a separate IP address range to that used by your other network enabled devices.

I would also recommend a crossover cable. You need it by default and using it reduces the chances of the hardware misidentifying itself when setting up the connection.

  • Thanks Lee, point about the crossover cable is very helpful. The value of DHCP though is for me when the laptop might serve multiple separate passive machines and they might not be configured to have a certain IP.
    – r0berts
    Feb 15 '17 at 9:49
  • 3
    Gigabit NICs are auto-MDIX, so unless you've got old 10/100Mb network cards, the cable does not need to be crossover. Just any Ethernet cable CAT5e or better will work fine.
    – dr_
    Feb 15 '17 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.