--Pat.
"Traditional" ARP was used, and as far as I can understand (from
looking at Explorer code) the (datalink) Chaos trailer (dest, source,
crc) was empty/ignored (but existing) in the Ethernet packets.
-- Bjorn
--Pat.
I have used it relatively much lately, implementing Chaos-over-UDP for
the KLH10 emulator (running ITS), interfacing/bridging this to
Chaos-over-unix-sockets for the CADR emulator, and most recently
interfacing/bridging Chaos-over-UDP to Chaos-over-Ethernet to let the
Symbolics machine talk to the others (still minor things to clean up).
-- Bjorn
I'm still trying to figure out how one would go about using ARP for
anything other than IP.
A good start could be the BSD (4.1?) implementation, which was also
ported to Linux (see e.g. http://www.heeltoe.com/software/hacks/chaos/)
- I haven't seen it in action though.
> I'm still trying to figure out how one would go about using ARP for
> anything other than IP.
That's the easiest part. ARP is protocol neutral, you just fill in the
protocol types and address lengths. I've implemented this in the
Chaos-over-Ether to Chaos-over-UDP bridge.
-- Bjorn
I'll admit to not knowing *quite* enough about the network code to know
if it's easy or not - I'm sort of given pause by seeing that the man
page for arp (at least in pre-6.x versions of FreeBSD) has text to the
effect of "ARP is not specific to either Ethernet, or IP, but this
implementation supports only that combination" (or words to that
effect). I know that there's support for things other than Ethernet
(such as ARCNET, Token Ring, FDDI), but the kernel code does appear to
make some assumptions that ARP is not used by anything other than IP.
I'm not real sure how easy it would be to make the necessary changes to
let ARP be used by any other protocol family.
There are also some changes needed to the user space "arp" command,
because it's also hardwired to believe that IP is the only thing that
will ever be trying to use ARP.
--Pat.
> I'll admit to not knowing *quite* enough about the network code to know
> if it's easy or not -
Read Stevens/Wright, TCP/IP Illustrated, Volume 2. At least everything
between ip_output() and ether_output() and ether_input() and the ARP
stuff. There are nice call diagrams, too.
Then read my paper "The New Link-Level Independent ARP Subsystem of NetBSD"
[1]
> I'm sort of given pause by seeing that the man
> page for arp (at least in pre-6.x versions of FreeBSD) has text to the
> effect of "ARP is not specific to either Ethernet, or IP, but this
> implementation supports only that combination" (or words to that
> effect). I know that there's support for things other than Ethernet
> (such as ARCNET, Token Ring, FDDI), but the kernel code does appear to
> make some assumptions that ARP is not used by anything other than IP.
> I'm not real sure how easy it would be to make the necessary changes to
> let ARP be used by any other protocol family.
I've changed NetBSD ARP to be able to use non-Ethernet as the layer below.
Back then, the Free- and OpenBSD network gurus I concated seemed not to be
interested, although I think that some FreeBSD activity happened later; the
guy in question pointed out a potential problem to me.
I didn't think about a different upper layer. But the method would be the
same:
Basically, it's easy - remove the fixed-size field definitions for the
ARP payload, create access macros, use them everywhere.
ARP packets have the length of the addresses embedded, so you can use
them everywhere once you have set them.
So you'll need changes to the PF_INET/AF_INET part of ether_output(),
which are minor, and add the PF_CHAOS part.
Of course, you'd have to check for consistency, especially on received
packets; and add the PF_CHAOS case to the switch in the ARP-input function
in the ethernet input path.
No real performance problem should happen, as ARP results are cached for
long times (several seconds at least).
Regards,
-is