hi,

I have a question: how can the ARP code be divorced from Ethernet
drivers, and be used  for a non-Ethernet device, specifically
a packet-mode driver for Metricom Ricochet radios?

Some background:

The Ricochet is a 904-920 MHz, frequency-hopping, packet-mode radio
device, which exchange packets at 100 Kbits/sec.  Metricom markets
these as "modems", with a Hayes AT-compatible interface implemented on
top of reliable streams over the packet-mode radio.  Metricom also
sells ISP service, using the modem-emulation mode, and a "modem bank"
of Ricochets at a Metricom POP -- essentially selling wireless PPP
service.


Prof. Mary Baker and Stuart Cheshire in the Mosquitonet group at
Stanford have defined a packet-mode IP encapsulation for the Ricochet
devices.  The MosquitoNet group (http:/mosquitonet.stanford.edu) has written a
Linux driver for this packet-mode encapsulation.  I subsequently wrote
(or ported) a NetBSD driver using the same encapsulation.  


This encapsulation is a true, peer-to-peer, datagram-addressed
service; it does not use the Metricom PPP service in any way.  It can,
however, use Metricom repeaters (aka poletops) to forward packets.
This is interesting to at least some NetBSD people, because Metricom
service is ubiquitous around the San Franciso Bay Area; and once you
have a radio, the Ricochet is a zero-marginal-cost service.


The problem is: the Ricochets are datagram-addressable devices (using
an 8-character ASCII "phone number".)  Because the radios are
spread-spectrum frequency-hoppers, they're not broadcast devices in
the same sense Ethernet or Wavelan is: not all radios will be
listening at the same frequency at each packet time.

The MosquitoNet design approach is to pre-load the radio MAC
addreseses (8-digit phone numbers) and associated IP addresses into
each machine's ARP cache.  They've added a new ARP encoding for Linux
specifically to do this.

That seems to me like a sound design (compared to the alternatives),
and I'd like to follow it.  However, doing that will necessitate some
non-trivial changes to the ARP code, which is currently tightly
coupled to Ethernet-specific subroutines.

The potential problems I've seen, after a first pass at this, are:

	 * It may be difficult to make a pseudo-device (the Metricom
	   driver is based on SLIP) look like a "struct arpcom".
	   I haven't looked further at this.

	 * The assumption that only Ethernet devices need to look up
	   and/or enter ARP addresses nees to be removed.

	 * The ARP table needs to support a hardware address type
	   other than 48-bit Ethernet/IEEE 802 addresses.

	   (a packed-BCD encoding would work, but it's just too gross
	    to contemplate.  Ouch.)


	*  Because the Metricom radios are not broadcast-addressable,
 	   using ARP in this way would  mean updating the ARP lookup
	   code, so that if an ARP lookup is done for an address
	   reachable via an interface that DOES NOT have IFF_BROADCAST
	   set, the ARP layer  fails immediately, rather than
	   trying to broadcast an ARP address.


What the current NetBSD driver does is to hard-code in a mapping
from a small number of IP addresses to Ricochet addresses.  That
doesn't even scale to the number of Ricochets on-campus here at
Stanford, let alone for use elsewhere.  I don't see any alternative
to *some* kind of table lookup, and the ARP table seems like the
most appropriate thing to use.


I'd appreciate any advice or suggestions anyone could offer here.
If someone from Core could comment on the likelihood of buying
back changes that address the above problems,s that'd be great too.