>>>>> "Don" == Levinson, Don <DLEVINSO@atu.com> writes:

    Don> Any progress on the token ring driver for NetBSD?  also my
    Don> understanding is that there are two distinct chipsets used
    Don> for almost all token ring cards. does anyone know which chip
    Don> set is being developed in the driver?

I've got a problem with my token ring driver for a Proteon p139x token
ring card: I may not be able to distribute it because of concerns over
disclosure of proprietary information.  This may take some time to
resolve either way.  It is for the Texas TMS380 family of token ring
controllers.  (The Linux token ring driver is for the IBM/Tropic
chipset).

The device driver itself is reasonably stable now; I have moved on to
looking at the ARP code and how it can be made more generic to support
networks with a different bit-order than Ethernet.  There are no such
restrictions on distribution in this area.  

If you're knowledgable about ARP, please review this:

Observation of network traffic has shown me that the hardware
addresses in the data part of an ARP request or reply vary in bit
ordering between:
+ Ethernet operating with ARP hardware type 1 (ARPHRD_ETHER) and
+ token ring operating with ARP hardware type 6 (ARPHRD_802) networks.

It's not clear to me whether the bit-ordering of the ARP packet
*contents*, depends on the actual network type or on the ARP Hardware
Type field.  Surely it must be the latter (for instance becuase you
can't tell, as the receiver of the packet, what network type the frame
originated on).  Internally to NetBSD, the ARP cache represents
hardware addresses in Ethernet bit order.  Here's a table of the
bit-swaps I provisionally intend to put into the more generic ARP
code:

   arp_hrd         if_type       swap?    Comment
   --------------------------------------------------
1. ARPHRD_802      IFT_ISO88025  Yes      normal Token ring case
2. ARPHRD_ETHER    IFT_ETHER     No       normal Ethernet case
3. ARPHRD_802      IFT_ETHER     Yes(?)   e.g. bridged token ring -> eth
4. ARPHRD_ETHER    IFT_ISO88025  No(?)    e.g. bridged eth -> token ring

So basically, I'm going to ignore what type of network the ARP packet
is received on, and just look at the the ARP Hardware field.  The only
case I can think of where this is dodgy is if someone transmits an ARP
packet on an 802.3+802.2 network with ARPHRD_802 - then there is no
way to tell whether to bitswap the received addresses or not,
especially once the packet has been through a bridge.

Another question is what type of ARP packets to generate on token
ring, or even generally.  My first guess is always to generate
ARPHRD_ETHER packets, because I have heard on the grapevine that this
is what other implementations do.  (It's also so much simpler, because
it means I don't have to consider the if_type of the outgoing
interface when building the ARP packet.)  However I know that some
routers transmit ARP packets on token ring with ARPHRD_802, and I
don't know if they will interpret the packets I send in the way
indicated in the table above.

-- 
        -- John Messenger, Proteon International (jlm@proteon.com)
	   "Mind like parachute: only works when open" -- Charlie Chang
           These statements are just my opinion.