IP addresses for embedded device with ethernet

David Brown wrote:
> 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.

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)
block. It would work directly with a fairly
recent Windows or MAC with a cross-over cable.
Please note that this is against the zeroconf
specification <http://www.zeroconf.org/>.

HTH

-- 

Tauno Voipio
tauno voipio (at) iki fi

packer44@hotmail.com wrote:
> "Perhaps you missed the part..."
> 
> I missed it because it wasn't stated ...
> 
> -D
> 

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

larwe wrote:
>>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
> 
> 
> 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).
> 

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.

> 
>>problem, but is there any way to achieve this effect using a normal browser?
> 
> 
> 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.
> 

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

Paul Marciano wrote:
> David Brown wrote:
> 
>>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.
> 
> 
> 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).
> 

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.

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

Tauno Voipio wrote:
> David Brown wrote:
> 
>> 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.
> 
> 
> 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.
> 

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.

> -- 
> 
> Another possible way would be to pick a fixed
> default address from the zeroconf (169.254.x.y)
> block. It would work directly with a fairly
> recent Windows or MAC with a cross-over cable.
> Please note that this is against the zeroconf
> specification <http://www.zeroconf.org/>.
> 
> HTH
> 

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!

David Brown wrote:
> Tauno Voipio wrote:
> 
> 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!

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

Hi, David,

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:435f66da@news.wineasy.se...
> 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.

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

Don wrote:
> Hi, David,
> 
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
> news:435f66da@news.wineasy.se...
> 
>>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.
> 
> 
> You don't state what resources (services) you expect to be available
> in the user's environment.  :-(  (e.g., a home, office, university, etc.)
> 

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.

> 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?")
> 

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

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

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

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

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.

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

Many thanks for the ideas.

mvh.,

David

"David Brown" <david@westcontrol.removethisbit.com> wrote
> Don wrote:
> > "David Brown" <david@westcontrol.removethisbit.com> wrote
> >
> >>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.
> >
> > You don't state what resources (services) you expect to be available
> > in the user's environment.  :-(  (e.g., a home, office, university,
etc.)
>
> 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 (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.

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

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

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

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

> > 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
>
> 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.
>
> > <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)
>
> Many thanks for the ideas.

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.

Don wrote:

<snip to save space>

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

Thanks (again) for the information - I'll be keeping a copy of it for 
future reference.  I fully agree that we'll need to use different 
techniques for different markets - with this thread, I've been trying to 
gather some general information and ideas so that I know what the 
possibilities are.

> P.S.  Look into NetBEUI also.

I was under the impression that NetBEUI was very much on the way out, 
and not even supported on newer windows (at least, not by default). 
NetBios over TCP/IP is an option for a local naming services, but I 
don't know much about its implementation.  Is it a straightforward task? 
  I'm only thinking about the naming protocol, not file or printer 
sharing or any sort of authentication or directory services.