Aviator2.4 firmware version 5 vs. ray driver
Dave Huang
> tcpdump has been ported to Windows and is called "windump". The
> URL is: http://netgroup-serv.polito.it/windump/ .
Oh cool, thanks! :) Well, according to windump, and another program I
found called "SpyNet", the Windows machine isn't seeing any incoming
packets at all.
Dave Huang
the firmware in both of my Aviator2.4 cards, since apparently, the
Windows 2000 driver needs it... so now I've got:
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
(same for the other card, except for the 802.11 address)
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...)
Also, the Windows driver has a setting for "Framing Mode", with
Translation and Encapsulation as the two choices and Translation being
the default. The docs say to use Translation in Ad Hoc mode, and to ask
the network administrator which to use if there's an access point. I
tried changing it to Encapsulation, but that didn't seem to change
anything.
So, any ideas? :) I don't have a packet sniffer for Windows, so I can't
tell what's going on on that end... I'll try to look for a downloadable
one though.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@bga.com | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 24 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
John Nemeth
}
} So, any ideas? :) I don't have a packet sniffer for Windows, so I can't
} tell what's going on on that end... I'll try to look for a downloadable
} one though.
tcpdump has been ported to Windows and is called "windump". The
URL is: http://netgroup-serv.polito.it/windump/ .
}-- End of excerpt from Dave Huang
Christian E. Hopps
> 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
>
> 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.