The port of the Mach token-ring driver (Tropic chipset) to NetBSD is working
fine. It works with every IBM card I threw at it and the 3Com 619B
TokenLink III.

One problem remains: source routing.

Matt Thomas advised a long time ago to make the llinfo_arp struct of variable
length and just append the route info fields. This seems pretty logical, but
there's one case I recently found in the release notes of the NeXT token-ring
driver:

If you have a Multi-Ring network and your sending a BOOTP request (broadcast !)
from one ring to be answered by the BOOTP server on another ring, the
broadcast contains source route info that is needed when the reply is sent.

When the BOOTP server replies it'll set an arp entry for the
(ip-address, mac-address) pair it knows from the various fields in 
the BOOTP structure but it doesn't know about the source route info
that was sent with the request.

It's easy to detect a broadcast with source route info but where
should that information be stored, somewhere in the route tree perhaps ?
Or a separate radix tree containing MAC --> Source Route mappings ?
If that's the case the ARP handling should be made much more general.
(Note that the 4.4BSD book says "Although ARP is not specific either
to Internet protocol addresses or the Ethernet, the 4.4BSD network subsystem
supports only that combination, although it makes provision for additional
combinations to be added) (additional == addition in the book).

How general should the source routing solution be ? In case of a token-ring
network with lots of IPX traffic you don't want to add all these source
routing bits to the table, or do you ?

Onno