How to write a Device Discovery Tool using Bash

Solution 1:

If you use avahi on your embedded PC you won't have to re-invent/re-implement service-discovery

On embedded PC:s:

apt-get install avahi-daemon
systemctl enable avahi-daemon --now
un-comment #publish-workstation=yes in /etc/avahi/avahi-daemon.conf
systemctl reload avahi-daemon

On machine used to discover embedded PC:s

apt-get install avahi-utils
avahi-browse -atr #  will output names and ip:s of devices on network to terminal

Solution 2:

As posted, the problem looks too wide. As I understand, you have two different problems:

1. Generate a method to avoid the problem in future cases.
2. Access to the servers that currently have the problem, to implement solution 1.

For problem #1, instead of getting a way to know the new IP, you could have the servers recover the old IP to a fixed value. You could set a crontab task that checks the current IP, and whenever it deviates from a set value, it changes the IP back to the target. You will of course have time windows of "network-blindness", depending on the frequency set in crontab.

Alternatively, a crontab task could broadcast/send email/etc. the new IP. The right mechanisms depend very much on what are you willing to operate, how are you accessing the servers.

All this seems a workaround. If correctly configured, they should not "forget the PC IP address". This is the point to fix, I guess. If you could give more information on the current configuration, that will narrow the problem.

For problem #2, if that is your target please mention it. I have a "similar" problem. A server that I am accessing remotely changes IP once in a while, since it is assigned by DHCP. Whenever I have problems sshing to the server, I execute a small script that, by a combination of ping and ssh (within a loop of IPs), and checking on the response, can get the current IP. Depending on many aspects of your network configuration this may work for you or not.

Solution 3:

I guess the farmers are reconfiguring it because their local network address changes. In which case, why not allow the server to get it's address over DHCP, you could make a note of the Mac address (which won't change) and then search the DHCP servers tables or even try a lookup on the DNS server to find the pc. Unpluging the cable from the end at the switch and plugging it back in should initiate a DHCP configuration session. Most DHCP servers allow you to assign an address based on a Mac address so you have some control over it at the dhcp server end.

Solution 4:

With netcat you could do something like a cronjob on your "pole-mounted servers" that does something like this every X minutes:

#!/bin/bash

# replace eth0 with the name of your interface or get the IP via other means

ip="$(ifconfig | grep -A 1 'eth0' | tail -1 | cut -d ' ' -f 10)"
datum=$(date)
echo "This is my IP: "$ip | netcat -q 2 -b -u 255.255.255.255 12001

The User/Farmer then only has to listen like this:

echo | nc -ulp 12001

And after X minutes they should get something like this:

This is my IP: 192.168.1.121

This only works if the "Farmers PC" and your "pole-mounted servers" are in the same subnet, though.

Explanation:

The script will send a UDP broadcast on Port 12001 and exit nc, after the payload (our echo command) + 2 seconds. The IP doesn't have to be got via ifconfig obviously, but its quite easy to parse..

Sending it to 255.255.255.255 means broadcast to the whole subnet, regardless of size.

So we don't have to know which network we are on.

On the client side, we listen with nc until we get a payload. I found nc terminates cleanly in combination with a line-break (via the echo).