IP addresses for embedded device with ethernet

If I build an embedded system with an ethernet port and a little embedded web server, what is the best way of identifying its IP address? It is easy enough to get an address on most networks with DHCP, but how does the user know so that they can type in the address in their browser? Any ideas would be appreciated.

TIA.,

David

Reply to
David Brown
Loading thread data ...

"David Brown" a écrit dans le message de news: snipped-for-privacy@news.wineasy.se...

Usually these kind of devices (for example network printers, etc) are supplied with a "discovery" software, that use broadcasts to find the avaiblade devices : Your system will answer to the broadcast and give its IP adress.

Cheers, Robert

Reply to
Robert Lacoste

Yes, that's one way I'd already thought of, and I suspect it will be the best method. As far as I can see, UPnP works in this way (though it has a great deal of overhead that I would not need, including the overhead of a bad reputation). Writing such software would not be a great problem, but is there any way to achieve this effect using a normal browser?

mvh.,

David

Reply to
David Brown

The UPnP boondoggle is a lot more than that, and sane persons run with it disabled in any case due to security issues. There are other technologies such as Apple's Rendezvous, but really all it boils down to is some "standardized" discovery mechanism (plus a load of overhead in the form of required metadata).

If you can assume:

a) your device HAS a valid IP address, b) there is a working Internet connection reachable by your device,

you can use one of a number of various dynamic DNS services to locate it. The unit would need a unique ID printed on the label, possibly derived from the MAC. It would publish its IP address to a DDNS service

- not necessarily anything standards-compliant, it could be something you run on your own web server. The user would read the ID off the label, go to your web site, and use the ID to look up his IP address.

Reply to
larwe

You will have to build your own discovery application for the host computer. To do this you'll use a UDP broadcast packet on a dynamic port. The application will know the first half of the MAC address which hopefully is under your control (You bought the MACS from IEEE) or perhaps you just use the explicit MAC address as an input to the discovery program. Put some data in the packet payload such as "DavesZippyIPUnitDiscovery". If the unit sees the broadcast with its MAC or OUI portion of the MAC, and identifies the packet data, it can send a response packet with it's IP address...

JMHO,

-D

Reply to
packer44

Perhaps you missed the part where the OP said he'd studied this and wanted to know of solutions that would work WITHOUT custom software on the end-user's network.

Reply to
larwe

You could have a default IP address. My home DSL router comes configured like that, as do some other networking boxes I'm aware of.

The user can plug a PC/laptop directly into the device, set their own IP to the same subnet and browse in. They can then enable DHCP or set a fixed IP address on the device and plug it in to their local network.

If you use DHCP you should make sure you can bind it to a local DNS name. If your DNS and DHCP servers don't talk to each other (mine don't) then you can tell DHCP to give out a fixed IP address for that device and then configure that into your DNS server (or use the address directly if you don't have access to a local DNS server).

We had a network printer here that simply used DHCP and discovery software on the PC. All was fine until the power went out and the device came back with a different IP address (the discovery software didn't rerun automatically).

Paul.

Reply to
Paul Marciano

"Perhaps you missed the part..."

I missed it because it wasn't stated ...

-D

Reply to
packer44

Read the message I was replying to.

Reply to
larwe

Ship it with a known, default IP address.

They configure the DHCP server so that it gives a known IP address to the device in question.

--
Grant Edwards                   grante             Yow!  I smell like a wet
                                  at               reducing clinic on Columbus
 Click to see the full signature
Reply to
Grant Edwards

I've met some boxes for process control, where the MAC address was printed very clearly for the following set-up procedure:

- feed the MAC address and the IP desired by you into the ARP cache of the host computer,

- use the IP above to connect to TCP port 0 with Telnet,

- the box will adjust to the IP mentioned above.

This procedure is based on the embedded box IP stack ignoring the target IP when it does not have an own. Also, the port 0 is not a proper one to use (by the RFCs).

The procedure also requires that the target box and the controlling computer are in the same LAN segment.

For Windows boxes, there must be at least one other (pingable) host in the network: the ARP cache refuses to be force-fed if it's empty.

--
Another possible way would be to pick a fixed
default address from the zeroconf (169.254.x.y)
 Click to see the full signature
Reply to
Tauno Voipio

I didn't say I had to avoid custom software on the user's PC in my original post, as I don't *have* to avoid it. I'd like to, if it is possible, but I'm not sure it is going to be practical to avoid. I've a number of ideas already as to how to implement a discovery application, but I'm always happy for more.

mvh.,

David

Reply to
David Brown

I've heard about the horrors of UPnP before (including from you, IIRC :-), and have no plans of implementing it. I was merely using it as an example for the underlying technique for discovery.

I'm not sure I can assume that - I think (a) is safe, but not necessarily (b). However, that is definitely a possible arrangement. I think what I might look for is to combine this technique with a downloadable discovery program at the same site, so that both methods are covered. It might also depend on the application - we have a few different ethernet-connected cards in the pipeline.

mvh.,

David

Reply to
David Brown

This makes sense for equipment like a router, which is typically alone on the network and is often the DHCP server. For other devices, however, it is not ideal.

Reply to
David Brown

That's an interesting idea, but requires a bit more competence for installation. I think it would probably be best wrapped within a custom discovery application. Where this technique is useful, however, is when there is no DHCP server on the network.

The Zeroconf website looks like it will be worth a read - perhaps I can get something out of it.

As far as I can see, there are zeroconf addresses in the multi-cast range 224.0.0.37 - 224.0.0.68. There are also quite a lot of unused multicast addresses in the "ad-hoc" block (224.0.2.0 - 224.0.255.0). The advantage of this range is that default routing tables on PCs use the local network rather than passing the packet on to the default gateway, regardless of the addresses used locally. Could one of these be (ab)used? What I'm thinking of here is that the board would first get itself a valid IP from a DHCP server (assuming there is one). However, it would also list to http requests on, say, 224.0.255.0. Whenever it gets a request there, it responds with a redirect to the valid IP address it has been allocated.

One issue with that is what happens if there are two such nodes on the network? I guess I'm going to have to read up on how multicast works!

Reply to
David Brown

Multicast is probably too complicated to handle in a simple embedded device.

The default 169.254.x.y range has 65536 addresses. If you switch on your box before the directly-connected PC/Mac, your box should perform to the spec by defending its address, in case the box at the other end happens to get exactly the same address (which already has a pretty small probability). For defending, it suffices that the box responds to ARP correctly.

If this was my embedded construction, I'd just pick one (e.g. 169.254.42.42) and use it. For accessing the embedded box, it's essential that the address is fixed (though against zeroconf spec).

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

Hi, David,

You don't state what resources (services) you expect to be available in the user's environment. :-( (e.g., a home, office, university, etc.)

Traditionally, RARP, BOOTP and DHCP have been used to assign ("allocate" may be a better choice of words in the case of DHCP) an IP to a MAC. Each protocol maps a MAC to an IP -- on request from the device *having* the MAC (i.e. the device essentially asks "What is *my* IP address?")

But, each of these require the respective service to be operational on a host (server) somewhere on the network in question. AND, each requires the service to have been *configured* by some entity (i.e. someone has to build the static map -- bootptab(5), ethers(5), etc. -- that defines the IPMAC relationships OR the dynamic map that allows DHCP leases to be let).

While this approach works well in an "organization", it won't fly in the home market. Instead, the typical approach is to have your device boot with an RFC 1918 IP -- which can be conveyed to the user in printed documentation (i.e. EVERY one of your devices uses the same default IP, typically).

This works "adequately" for small home networks where the device remains on that *private* (i.e. non-routed) network.

But, it requires special care if multiple like-devices are present (since they ALL will assume that same default IP). There are (clumsy) ways around this but they get to be a hassle for Joe Average Consumer (i.e. you don't want to spend lot$ answering the same support questions over and over...)

If the device is on a *public* (i.e. routed) network, chances are the user has staff available that can (easily) support it using their existing IP management tools. These can include RARP, BOOTP, etc. Or, a more "manual" scheme along the lines of:

- device powers up with a default "factory assigned" RFC 1918 IP

- staff puts the device on a small network (maybe just one other machine!) known not to have a conflict with said IP address

- staff accesses configuration utility within your device via a web server in the device... *or* even a telnet connection (!)

- staff *sets* the necessary options in your device (IP, netmask, etc) to suit their addressing conventions

- staff tells your device to store these in NVRAM so subsequent resets will not require a repeat of this procedure

It's not an ideal solution -- ESPECIALLY if that organization has a

*lot* of these to deploy/maintain. In that case, it's usually easier to maintain the configurations centrally on a DHCP/BOOTP/RARP server (that's how I handle the dozen or so devices here that boot without IP's)

HTH,

--don

Reply to
Don

I'm thinking in general for a few different devices, which could be in different environments. Some devices may be used in environments where we can expect a knowledgeable user, some in office-type networks, some in home-type networks, and some in completely closed networks that we have full control over (then it's easy :-). I'm looking for ideas in general as to how to solve this sort of issue for current and future boards - I also expect that I'm not the only one reading this who is interested.

I think both RARP and BOOTP are only suitable for more specialised networks, with qualified network administrators. DHCP is, as far as I have encountered, very common in office networks and home networks (the server being a firewall/router/broadband gateway device).

One problem with RFC 1918 addresses is the PC's routing tables. It's fine to have a specific address for some applications (like a broadband router/gateway, where the device defines the local network address), but if I pick, say, 192.168.10.5 as my default address, and the user has a small network on 192.168.4.x, then any attempts to access 192.168.10.5 will be passed on to their default gateway and head off into cyberspace (unless I've missed something here).

Indeed - if it is to be accessed publicly, then there are far more issues and it will need someone knowledgeable to do setup. I'm not expecting to make publicly accessible devices in the immediate future.

Many thanks for the ideas.

mvh.,

David

Reply to
David Brown

etc.)

I think (IMHO) your best bet is to aproach each environment differently. I.e. don't expect a one-size-fits-all solution to work.

For example, I find consumer devices a real nuisance to configure since they *expect* to be on small (home) networks. They don't expect to conflict with an existing ddressing scheme since they tend to assume there aren't many other devices there! And, the schemes for "customizing" them usually require me to have a dummy "two host" network available just so I can talk directly to that *one* device to tweek it to play well with the other boxes here.

This is very labor intensive. I'd prefer to read the MAC off the label on the back of the unit, type that into my ethers(5) and let a *server* deal with assigning, maintaining and *documenting* (!) the address tied to this device (instead of having to maintain logbook entries: "Configured Widget9000 to reside at a.b.c.d/24"

OTOH, for those products *targeting* the home market, it may be perfectly safe to just *pick* an IP and expect it to be adequate. Those few users with more than a couple of nodes that *might* have conflicts could be expected to go to some extra lengths to customize their units (using the "two host network" approach).

Office environments are, IMO, the tricky ones. Too many of the folks rnning these think they know more than they actually do :-( So, treating them like novice "home users" will often result in a service call when your device conflicts with some *other* device that takes an equally naive approach to IP assignment ("What do you mean, I have to assign an IP address? What's *that*? How do I find out which IP address to assign? How do I find out what IP addresses are already in use here? etc.")

But, the opposite approach is equally perilous -- expecting the "office manager" to be savvy enough to know how to configure a DHCP/BOOTP/RARP/etc. server. You're just as likely to end up with service calls from those folks wanting a free Networking 101 course...

You also need to decide if you are likely to be "playing with others" in each of these markets/application domains *or* if your likely net-neighbors will just be other boxes that you have designed! In the latter case, you can adopt simple schemes that allow your devices to cooperate in slf-assigning their own IP addresses.

Yes, but this assumes a black box approach to deploying your device. Little (if any) control over IP assignments on the behalf of the user (i.e. if the user wants to talk to *your* box, how does he know "where it is" *today*)

Assuming a netmask of 0xffffff00, yes. Note my earlier complaints about my need to maintain a two node network just to deal with consumer devices... :-(

Again, I think you should try to treat each application domain separately. Develop solutions for each independantly. If you later want to come up with a common code base for *all* of them, then you can bury some configuration switches in the code (possibly not even user accessible) to decide which srategies the device adopts for address discovery.

For example, the X Terminals that I use have *dozens* of configuration options related to basic configuration (address discovery, name resolution and bootstrap protocols) as they tried to be "everything to everyone". A similar approach could let *you* be everything to everyone WITHOUT intimidating them with that long list of options...

--don

P.S. Look into NetBEUI also.

Reply to
Don

Agreed! :>

Understood.

That's quite possible. I haven't used a MS product since W98 so I'm not the right one to comment. As with every OTHER technology, I'm sure MS will *invent* TCP/IP any day now!! :>

NetBIOS doesn't scale well, can be easily abused, etc. I just mentioned it to get you thinking in other directions (again, not knowing what your specific applications and markets are...)

It is often beneficial to look at a variety of technologies even if they don't *seem* to fit your needs. Epiphanies come in many colors! :>

--don

Reply to
Don

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.