[Guy Harris <gharris@xxxxxxxxx>]

On Sun, Jun 09, 2002 at 02:52:56PM -0400, an ethereal user wrote:
> I put two sample caps on my web server:  http://www.severus.org/wifi-caps/

(You're the first of the people that have reported this problem who have
actually supplied us with capture files so we could try to figure out
what's happening.  Thanks!)

Wow.

It looks as if those packets have a *partial* 802.2 LLC header after the
802.11 header, with the DSAP and SSAP stripped out!

The purported LLC header of one of the LLC frames in "icmp-traffic"
contains

	0x03		(the 802.2 LLC control field value for a UI frame)

followed by

	0x00 0x00 0x00	(the SNAP header OUI field value for
			"encapsulated Ethernet")

	0x08 0x00	(the SNAP header protocol value field, with an
			OUI of "encapsulated Ethernet" - i.e., the
			Ethernet type field value - for IP)

This sounds either like

	1) a driver problem

or

	2) a card firmware problem

or

	3) a problem with the mode the card was in.

As this is the FreeBSD 4.5 "an" driver, I'm CCing Doug Ambrisko on this
one.

> Both of these caps were made with the following setup:
> 
> Network:   192.168.0.0/24
> Gateway:   192.168.0.1
>   OpenBSD 3.1
>   Intel Etherexpress Pro (fxp)
> Victim:  192.168.0.45
>   FreeBSD 4.5
>   Dell Truemobile 1150 (orinoco gold)
> WAP:  Linksys WAP-11 2.2
> Sniffer: (none)
>   FreeBSD 4.5
>   Cisco LMC352
> 
> The following commands were run on the sniffer immediately after boot:
> 
> [root@ocelot root]# ancontrol -i an0 -M 7
> [root@ocelot root]# ifconfig an0 up
> [root@ocelot root]# ethereal &
> 
> Capture options were left as default
> 
> - icmp-traffic
> 
>  (from victim) # ping 192.168.0.1
>      10 pings and responses, 0% loss
> 
> - google-session
> 
>  (from victim) # nc -vv www.google.com 80
>    GET / HTTP/1.0
>    <response>
> 
> In the google-session cap, the HTTP request is sent in frame 206, and the
> response begins at frame 228.  There should be a DNS resolution somewhere in
> there, along with the normal TCP session setup.