Subject: Re: Aviator2.4 firmware version 5 vs. ray driver
To: Dave Huang <firstname.lastname@example.org>
From: Christian E. Hopps <email@example.com>
Date: 03/02/2000 15:03:53
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
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.