Re: IP addresses for embedded device with ethernet
- From: "Don" <None@Given>
- Date: Tue, 1 Nov 2005 09:39:17 -0700
"David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
> Don wrote:
> > "David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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.
.
- Follow-Ups:
- Re: IP addresses for embedded device with ethernet
- From: David Brown
- Re: IP addresses for embedded device with ethernet
- Prev by Date: Re: Getting the code size of a function in C
- Next by Date: Re: Getting the code size of a function in C
- Previous by thread: Getting the code size of a function in C
- Next by thread: Re: IP addresses for embedded device with ethernet
- Index(es):
Relevant Pages
|
Loading
