On Wed, Mar 01, 2000 at 12:49:17AM -0600, Dave Huang wrote:
> ray0 at pcmcia0 function 0: WebGear, PC Card WLAN Adapter, Version 5.63 May 1999
> ray0: firmware version 5
> ray0: supported rates 2:3:0:0:0:0:0:0
> ray0: 802.11 address 00:00:f1:11:80:ae
> 
> However, NetBSD no longer interoperates with Windows (if both sides are
> running NetBSD, or both are running Windows, everything works fine). It
> seems like Windows can't hear or understand the packets from the NetBSD
> machine. tcpdump on NetBSD shows that Windows is sending an arp who-has
> asking for NetBSD's MAC address. NetBSD sends the reply, but Windows
> doesn't get it.
> 
> I've got LINK0 on the NetBSD side, but I did try it with LINK0 off, in
> which case tcpdump showed the incoming packets okay, but couldn't
> interpret the outgoing packets and just showed them as a hex dump (that
> doesn't sound right to me...)

Can you be more specific on when you see packets and what they look like
based on the link0 flag?

Since you have 2 choices on both OSs thats 4 combinations.  It would
probably be useful to know what your seeing on both ends for each of
the 4 states.

Basically the link0 flag is dealing with how the frames are constructed.
For link0 I believe this is what the windows driver is calling
encapsulation.  A regular Ethernet 2 frame is wrapped inside an 802.11
LLC/SNAP frame.

For non-link0 the driver just uses a straight 802.11 LLC/SNAP header.

The reason it looks weird in tcpdump on output for the non-link0 case is
that tcpdump hasn't been taught yet how to read this frame type.
When link0 is on the driver just sends the E2 frame part to tcpdump.

Chris.