IP addresses for embedded device with ethernet

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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



Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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

Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


Re: IP addresses for embedded device with ethernet
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


Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it

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.


Re: IP addresses for embedded device with ethernet
"Perhaps you missed the part..."

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

-D


Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it

Read the message I was replying to.


Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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

Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it

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.


Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it

Ship it with a known, default IP address.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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)
We've slightly trimmed the long signature. Click to see the full one.
Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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!

Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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

Re: IP addresses for embedded device with ethernet
Hi, David,

Quoted text here. Click to load it

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 IP<->MAC 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

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



Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Many thanks for the ideas.

mvh.,

David



Re: IP addresses for embedded device with ethernet

Quoted text here. Click to load it
etc.)
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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*)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.



Re: IP addresses for embedded device with ethernet
Quoted text here. Click to load it

Agreed!  :>

Quoted text here. Click to load it

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!!  :>

Quoted text here. Click to load it

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



Site Timeline