Re: [ECOS] Temporary IP address assignment trick

[Jonathan Larmour <jifl at eCosCentric dot com>]

Grant Edwards wrote:
> On Thu, Mar 20, 2003 at 11:36:37AM +0000, Jonathan Larmour wrote:
>
> > Grant Edwards wrote:
>
>
> > > I've noticed that a couple embedded devices I've played with
> > > allow you to assign an IP address temporarily using an arp
> > > trick...
> > >
> > > If the device starts up with no IP address, and it subsequently
> > > receives an Ethernet frame with its MAC address, the IP stack
> > > will adopt the IP address in that frame as its own.  Typically
> > > one then points a telnet client or web browser at the device
> > > and configures its IP address permanently.
> >
> > [snip]
> >
> > > This is a very handy way to get a brand-new-out-of-the-box
> > > embedded device up and running without requiring a DHCP server.
> > >
> > > How hard would it be to get either of the eCos stacks to behave
> > > like that?
> >
> > This looks very similar to Reverse ARP, or RARP:
> > <http://www.networksorcery.com/enp/rfc/rfc903.txt>. This
> > technique is older than BOOTP I believe. Looking at the man
> > page for rarpd, I see it has a -A option that's probably what
> > you're seeing.
>
>
> It's not RARP.  RARP requires that the device broadcast a RARP
> request and then a server replies to that request (much like
> BOOTP).

Yep.

> The devices I'm playing with just sit there silently
> and if they receive _any_ non-broadcast IP packet with their
> MAC address, they'll accept the IP address as their own.  It
> can be an ICMP ping, a TCP SYN, anything.

Sure, although you still need a cleverly set up server to do this anyway 
(_something_ has to be listening for unfamiliar addresses), so RARP 
doesn't seem so different. But what I meant when talking about the -A 
option is that I think rarpd -A may do what you would want on the server side.

When the stack starts up "properly" it always does an ARP request for 
itself anyway, one of the reasons being to check there aren't conflicts 
with people with the same IP. It certainly means that you can't just bring 
the stack up completely unless you already have its IP address sorted out, 
so you can't let it work "transparently". Instead you would have to do the 
same intermediate sortof-up stage that BOOTP etc. does with an explicit 
phase to await an IP address. ether_demux() in if_ethersubr.c will 
certainly drop stuff unless the interface is up.

I would think RARP would fit easier into the way the stack is now.

> > As for getting the stacks to do it - I'd have thought it would be pretty 
> > simple - you only need to change init_all_network_interfaces.
>
>
> Is there a way to tell the stack to receive and turn over to
> the application any packet with a matching MAC address?

_Any_ packet? Probably not right now AFAICT. Again have a look at 
ether_demux() (called from ether_input()), that's where the fun is and 
certainly where IP and ARP packets go their separate ways.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss