1. Home
  2. Embedded Linux
  3. question about "discovering" a device on a network.

question about "discovering" a device on a network.

Hello,

We're working on a small appliance that has a linux/unix installed on it with our product. The challenge we are facing now is this. When we send out the device to a client, we would like to make it as easy as possible for them to setup.

The device needs an IP address so then the client can connect to the device via a browser on a given port to setup the configuration options.

The problem we forsee is the different environments and technical abilities our clients may have.

We've thought of these solutions and none of them sound very appealing to us.

... Client gets the device and plugs it into the network... and then...

Uses nmap to do a full network scan and try to figure out which device is our appliance... (seems to be too much work for our purposes) or.... We give the device a preset IP address (hoping that it won't conflict with other systems, and that it will match their network) -- (this is probably not feasible, are they using 192.168 or 10.10, or some other private address) or.... We tell the client to connect to the device via serial and configure it with a valid ip. (This seems to be the most reasonable option but the client may not have the knowledge to do this) or... We have our device "phone home" when they plug it in and we'll tell the client the ip configuration that it got. (this is too dependant on the ability of the machine to phone home, firewalls, blocked ports etc etc) or... We tell the client to plug it in, the device will get a DHCP address and they can just ask their network admin to look it up on the DHCP host table. (This may be impractical on a big company where a network admin is not easily available for this) or...

We've thought of a few other ideas but we're just trying to narrow it down to a couple of good solutions.

We don't like any of these ideas, and we think there may be a more elegant solution out there that we can implement. I'd greatly appreciate any input or ideas in the matter.

Thanks a lot for any feedback you can give me!

Oscar

Reply to
Oscar
Loading thread data ...

hi,

formatting link

apple has an open source implementation which works on embedded systems:

formatting link

andré

Reply to
Andre Frambach

This is a difficult problem. It depends on who your user is and what OS/network he is running on. I wanted a config that would work for ANY user and ANY network and ANY computer. This means running a custom program to "find" the target is not practical, and dhcp with names is way too wide a variation from network to network.

So my conclusion is universal AND automatic is impossible. So I ship my device with a fixed 192.168.... address. To configure the user has to get a fixed IP for his own LAN. This can be difficult for the user with a sufficiently user-hostile net admin. Then he must reconfigure his computer to an address on my devices 192.168.. net and directly connect my device to his ethernet port (must avoid collisions with his LAN). He then can open my devices web page and set his desired LAN address. Note that this technique is exactly what is used by Linksys (AKA Cisco) routers.

It is a real pain. Remember when TCP was new, there were like 50 computers on Arpanet, so lots of what we are trying to do was completely unthinkable.

Regards, Steve There is no "x" in my email address.

Reply to
Steve Calfee

Oscar,

I can't give you an answer, but here's some info.

Our devices ship with a default configuration of both a dhcp client, and a 192.168.0.1 address on an ethernet alias. This allows users to configure their own PC with an private IP address and access, or users with a dhcp server already present to access the device.

In the past, we've attempted to utilise multiple default configurations, where you can easily switch from config a) dhcp client, to b) static address with dhcp server. this caused confusing support issues for us, but may work for you.

good luck.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  | Damion de Soto --------------------------------------------------
  | Software Engineer   email:  Damion_deSoto@au.securecomputing.com
  | Secure Computing Corporation web: http://www.securecomputing.com
  | fax:        +61 7 3891 3630   ph:                +61 7 3435 2809
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ----  Free Embedded Linux Distro at  http://www.snapgear.org  ----
Reply to
Damion de Soto

Can you get the user to run a small "discovery" program on their PC (for example, as a web applet quickly downloaded from your website)? The great majority of networks support DHCP, so it's normally easy for it to get hold of a valid IP address. Your device can open a specific port for listening (pick a high port number that no one much uses), and the discovery program can broadcast a message to that port. That should be enough to get communication running.

Reply to
David Brown

Thanks Andre, we have thought about this but we think this may not work for us but I'll take a look.

Reply to
Oscar

I suppose that if we spent some time profiling our customers we could determine what the majority of them are using as far as networking and OS goes but I think the only concern is whether they are using DCHP or static in their network (nowadays with so many computers at each workplace, I would imagine most people do DHCP for 90% of their network.

This is indeed my option of choice, it is what I've seen in other devices and like you mention, linksys and other manufacturers already do this. I think it would be easier for a non-technical user to setup a computer with a 192.168 address than it would be for them to find a serial connector and use xterm or other telnet client to change a configuration via serial.

I don't think I was even a thought on my parent's mind at the time :) but yeah I can imagine that they never thought this "internet" thing would grow to millions of computers.

Thanks lot Steve.

Reply to
Oscar

Yup, this is what I was thinking...

This is assuming they are using a 192.168 DHCP network. It wouldnt work if they are using another private range like 10.10...

Thanks for your input!

Reply to
Oscar

This is another idea we thought about, exactly what you mention and we're exploring this possibility it seems that if we get it right it would be the easiest thing to do. However it is still assuming that the client's network is on a DHCP network.

Thanks!

Reply to
Oscar

I know of two different procedures that are used successfully in commercial devices.

1) "ARP"-Method

The device is labeled with it's MAC address (that is unique in the Universe). The customer connects the device to his PC via Ethernet, using a cross cable or a switch, but not a router.

Now he uses the ARP cache handling function of his OS (e.g. ARP -s ...) to assign some random IP address (taken from his local IP network range but not used otherwise in his network) to the MAC address of the device.

Now he accesses this IP address in a way defined by you (e.g. by opening a Telnet session on a special port).

The device is configured to accept opens on this port independently from the addressed IP address, even it does not match the one it is configured to. I don't know (yet) how this can be done with Linux, but I do know that it is possible. (Maybe it even is no problem as only the target MAC address is checked (by the Ethernet hardware/driver, maybe this can/needs to be done similar to "Multicast groups").

Now the device can either set it's own IP address to this IP address or continue with the Telnet session and accept manual configuration, or (for security purpose) accepts a standard Telnet session on the standard Telnet port to allow manual configuration.

2) "UDP-Broadcast"

The device should be labeled with it's MAC address (that is unique in the Universe). The customer connects the device to his PC via Ethernet, using a cross cable or a switch, but not a router.

With the device the customer is sent a program (preferably versions for the different Windows, Linux and MAC flavors).

You implement a propriety protocol that works via UDP broadcast (and perhaps partially via dedicated UDP sends) on a dedicated IP port.

The program has a "search" button. With this it sends out a UDP broadcast containing some constant byte string. Using a random (pre-configured) sender IP address, all devices answer with a UDP block that contains (among some more information, such as device type and software version) their Ethernet address. The program creates a list of the found devices and shows it to the user. Now the user can select one of the found devices and request to assign an IP address (and mask and gateway address) to it. Via UDP broadcast the program sends out a block that contains the target MAC address and the desired IP settings. The device that finds it's MAC address, now sets its IP configuration (on ifconfig and/or permanently in Flash for the next start).

This UDP protocol can be used to set other device parameters, reset the device, initialize firmware updates etc, too.

-Michael

Reply to
Michael Schnell

BTW.: as this a standard task with embedded devices, I suppose there is free source code available for either or both of these methods. Please let us know if you find it somewhere.

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.