If your Coughlinux device is "headless" (no monitor / keyboard), you might need a way to find it on a network. You could give it a static IP, but that complicates things if you want to connect more than one device because you'll have to keep IPs straight (i.e. ensure no two devices have the same static IP). You could set each device up as a server, but that can be even more complicated in a multi-device network.

What you'd really like is a way of getting the dynamic IPs of the Coughlinux devices on your system. Here are some ideas on the subject for your consideration. You'll notice that most of the approaches suggest anything but C or C++ solutions-that's primarily because I'm trying to stay as platform-neutral as possible and network I/O is about as platform-dependent as you can get in C/C++. As always you should feel free to do as you please though so there's no reason C, C++, Ruby, or (insert your language of choice here) wouldn't work.

1. Successive Pings

Easiest to implement, possibly the least user-friendly (i.e. if you hand the system over to someone else unfamiliar with your work). Just ping successive IP addresses: the IPs that don't time out represent devices on your network. Knowing your own IP address (e.g. through ifconfig or ipconfig), you can back out which IPs are used by your embedded Linux system(s).

The problem with this approach is that it can be labourious and it requires a certain level of expertise on the part of your user. I tend to use it fairly frequently, but it doesn't work so well with a project manager, our marketing crew, or any other PHB-type. :)

2. Auto-Ping

Second easiest to implement, a little more user-friendly. This simply automates the successive pings through all the available IP addresses and reports on the "live" IPs found.

Java SE 5's InetAddress class has a nice isReachable method that works well for this approach. You could also just use a simple script in your dynamic language of choice by just redirecting the ping results to a file and then searching for "live" IPs. A simple grep-ing would do much the same if you preferred a shell script.

Although this approach is much easier for the non-technical user, it still has the problem of just returning a list of "live" IPs. In other words it doesn't tell you where your device is, just where it might be. If it's just your laptop and your Linux device on the network, no problem. Once you begin adding more devices to the network, however, finding your Linux device(s) becomes a trial and error affair.

You should also consider using multi-threading or multiple processes with this approach, since it can take a while to go through all the different IP addresses. GUI applications in particular will feel like they've crashed if you don't, but if you don't want to go that route you should at least provide some sort of indication that your application's doing something, e.g. by printing the IP currently being checked to the screen.

Sweeper

Here's an example of a Java mini-app that uses this approach to find out who's "live" on the network. Feel free to grab a copy for yourself. To use it, just specify what I call the "base IP" (the first three octets in dot-decimal notation, e.g. 192.168.1, 192.168.0, 127.0.0, etc.) in the text box, and press the "Scan" button. Sweeper then attempts to ping each IP address in this base IP family (192.168.1.0, 192.168.1.1, ...) and when finished reports its results back to you. It can take a while to get through all the IP addresses so give it some time. A screenshot of Sweeper running under Linux is shown below:

As you can see it might be a handy little tool for some purposes, but it still requires a bit of technical expertise. And patience.

3. Page Fetching

Instead of just ping-ing IPs, why not just try to fetch a page from your web interface? If the fetch succeeds, you've found a Coughlinux device. Otherwise you can skip that IP and move to the next one.

The simplest implementation is to simply request a page, e.g. http://192.168.1.101/index.htm, and if you receive data you assume it's a valid device. However, you'll have better results if you allow for the chance that other devices on the network may be serving that same page by interpreting the data you get back. The simplest way to do this is to look for something in the returned data that only your embedded Linux devices should include: a product name, your name, a serial number (matched against a predefined list), and so on. Only assume that the IP in question belongs to your embedded device if this check passes.

Python's urllib module works great for this approach: as the documentation suggests simply subclass URLopener or FancyURLopener to handle the page fetches. You can then simply report the location(s) of the embedded device(s). I like to go one step further and use Python's webbrowser module to open the device's web interface. You might not want to automate this part if for example you expect to have more than one device on the network, but otherwise it makes for an (almost) foolproof PHB application. :)

As with the auto-ping approach you should consider multi-threading or multiple processes for this type of application. Personally I've found that just printing the current IP to the screen is enough to placate a user, but your results may vary.

4. Auto Discovery

The above methods assume your Coughlinux device is basically just a passive listener on your network. We can speed up the entire location process if we take the opposite approach and make your devices active-instead of searching the entire network, they'll tell us where they are!

In my own experience I've found that the magic of UDP works well for this application. A number of development environments (Java, REALbasic, etc.) have a convenient UDP library with a "broadcast" functionality, in which the message can be sent to every IP on the UDP network. In this approach, we simply instruct the Linux device to broadcast its location to everyone in earshot (i.e., every other device on the same network), and rely on a desktop application to be listening for these broadcasts.

In Java, the DatagramSocket class is the way to go. Just ensure that SO_BROADCAST is on (meaning that messages are broadcast) via the getBroadcast and setBroadcast methods, and send / receive as necessary. The DatagramPackets you send/receive should if nothing else contain the embedded device's IP address. Generally speaking you should plan on sending the same data packet several times-UDP doesn't have the same error-checking that TCP does and doesn't guarantee any one packet arrives at its destination.

The downside of this approach of finding your devices on the network is that it requires additional software on your device. If your language of choice doesn't produce a self-contained executable, you may be looking at installing runtime modules, additional libraries, etc. So what are your options if you don't have and don't want Java or Mono runtimes or Python installs on your device? Write it in C/C++, or another compilable language.

Or you can just download the apps I wrote. Either way. :)

Finder

As mentioned above, the excellent REALbasic language has full support for UDP and broadcasting messages. Although I originally considered using Java for this application, I really didn't want to install a full-blown JVM on my embedded device. A C or C++ project would work for this application, but I was looking for a good excuse to explore REALbasic.

Which brings me to Finder. Finder is a very simple system, built around the REALbasic UDPSocket class. The system has two parts: a console app that broadcasts the IP, and a GUI app to listen for incoming IPs. To use Finder, copy findercon to your embedded device. The console application accepts two command line arguments: -gGroupName, where GroupName is the name of the group you want to use (can be anything, REALbasic automatically converts to a valid IP); and -nNumSends where NumSends is the number of times to send the broadcast message (defaults to 7). Every 10 milliseconds or so, findercon will broadcast its IP to the group you've specified, and then exit.

On the GUI side of things, both a Linux and Windows client are available (if anyone wants a Mac version, let me know). A screen capture of the client running under WinXP is shown below. Just start up the GUI client, and enter the same groupname in the Group box as you previously chose for your embedded device. Press the Join Group button to begin listening, and Leave Group to stop. You may have to fiddle with your firewall, but you're probably used to that by now. :)

When the console app broadcasts its IP, a GUI client listening on the same group will update its list of IPs with the new IP. Double clicking on an IP will attempt to open that IP in your web browser of choice (e.g. browsing to http://192.168.1.101).

The Finder system only works across a single network, meaning that to work all the devices have to be on a network shepherded by the same router. It won't work if there's another network device in between, and it won't work on the same system (i.e. a single computer can't send and receive). That's a basic limitation of the API I used. If you'd like to test-drive the system before putting it on an embedded device, just run findercon (or its Windows equivalent) from one computer and listen on another on the same network using one or the other GUI client (each client works with both Linux and Windows console apps).

Finally, remember that these apps should be considered beta-quality and might (do?) have some quirks and bugs. Please use accordingly!

Available downloads listed below. I'm not sure about minimum processor speed or memory requirements but they're fairly minimal at any rate.

• Windows GUI. Should work for Windows 98, NT (4.0 or higher), ME, 2000, 2003 Server, XP.
• Windows Console. As above.
• Linux GUI. Requires GTK+ 2.0 (or higher), glibc-2.3 (or higher), and libstdc++.so.5. Confirmed to work under OpenSuSE 10.
• Linux Console. Requires glibc-2.3 (or higher), and libstdc++.so.5. Confirmed to work with base Coughlinux distro (with C++ support installed).

udp_finder

If you'd prefer a C source code example of auto discovery, this is for you. The simple little udp_finder program acts as both a client and a server, and will broadcast its IP and the contents of a serial number file to anyone on the network. The idea is that if you have multiple Coughlinux devices on a single network, it may be important to be able to distinguish one device from another (e.g. proximity detection, finding and fixing a damaged device, etc.). Since the code is based in part on code and concepts in Wikipedia's UDP entry, let's go ahead and say it's licensed under Wikipedia's GFDL.

In client mode, it broadcasts its IP and a command line specified serial number file to every IP in a network on a given port, e.g.

Will attempt to contact every IP address from 192.168.1.0 to 192.168.1.255. In server mode, it listens on the given port and reports all clients reporting in, e.g.

Will print the IP and ID of every client that "calls in." Confirmed to work in most Linux installations (including the base Coughlinux distro). You might be able to port the code with Cygwin to run in Windows environments, but as mentioned above networking code in C is very platform-dependent so your results may vary. I wrote a simple Windows client to keep a running tally of LAHMP units that report in; if you're interested I could probably be persuaded to give you a copy.

• udp_finder ZIP archive.