Ethereal-users: Re: [Ethereal-users] Wireless sniffing - FreeBSD 4.5 + Cisco LMC352?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Fri, 14 Jun 2002 00:03:51 -0700
On Thu, Jun 13, 2002 at 10:29:13AM -0400, Solomon Peachy wrote:
> On Wed, Jun 12, 2002 at 11:21:44PM -0700, Guy Harris wrote:
> > Perhaps we'd need to have a preference setting in the 802.11 dissector
> > to control whether to assume WEP frames are decrypted or encrypted?
> 
> Personally, I'd just leave it as it is.  Now that the 802.11 dissector can
> handle de-wepping data on its own, there's no real reason why we need to
> have the card do the decryption itself.  :)
>  
> > Solomon, what happens with the Prism II reference design cards in
> > monitor mode if they receive a WEP frame and the WEP key is set on the
> > card?  Do they supply the frame with everything including the WEP header
> > as is, but with the payload decrypted?
> 
> If the card is set to de-wep the incoming packets in monitor mode
> (keepwepflags=true, defaults to false) it strips out the WEP IV+ICV, but
> doesn't clear the WEP bit in the 802.11 header.  *grumble*  I was most
> displeased when I discovered this gem.

It appears that the Aironet card de-WEP's the packets but *doesn't*
strip out the WEP IV+ICV:

  From: Doug Ambrisko <ambrisko@xxxxxxxxxxxx>
  Subject: Re: [Ethereal-users] Wireless sniffing - FreeBSD 4.5 + Cisco LMC352?
  To: an ethereal user <ethereal@xxxxxxxxxxx>
  Cc: ethereal-users@xxxxxxxxxxxx, Doug Ambrisko <ambrisko@xxxxxxxxxxxx>
  Date: Mon, 10 Jun 2002 08:34:57 -0700 (PDT)

	...

  Also note that with the Cisco card you do not get the WEP keys in the
  "raw" 802.11 packet (so is it really 802.11 monitor mode ... not really).
  It is speculated that the WEP HW engine removes this.  I've been able
  to decrypt and view the payload correctly when I enabled WEP on the
  card and set the keuys then in Ethereal dissector I have it skip
  the WEP part of the packet and then Ethereal disects the rest of the
  packet correctly (ie. follow HTTP streams etc.).

  4.6 is about to get released.

  Guy, is there anyway that you want to handle the WEP issue for the Aironet
  cards?  This is the same issue in Linux.  Or have you already run into
  it?  My laptop with the change on it should be coming back today.

  Doug A.

  From: Doug Ambrisko <ambrisko@xxxxxxxxxxxx>
  Subject: Re: [Ethereal-users] Wireless sniffing - FreeBSD 4.5 + Cisco LMC352?
  To: Guy Harris <gharris@xxxxxxxxx>
  Cc: Doug Ambrisko <ambrisko@xxxxxxxxxxxx>,
     an ethereal user <ethereal@xxxxxxxxxxx>, ethereal-users@xxxxxxxxxxxx
  Date: Wed, 12 Jun 2002 09:55:12 -0700 (PDT)

  Guy Harris writes:
  | On Mon, Jun 10, 2002 at 08:34:57AM -0700, Doug Ambrisko wrote:
  | > Also note that with the Cisco card you do not get the WEP keys in the
  | > "raw" 802.11 packet (so is it really 802.11 monitor mode ... not really).
  | > It is speculated that the WEP HW engine removes this.  I've been able
  | > to decrypt and view the payload correctly when I enabled WEP on the
  | > card and set the keuys then in Ethereal dissector I have it skip
  | > the WEP part of the packet and then Ethereal disects the rest of the
  | > packet correctly (ie. follow HTTP streams etc.).
  | 
  | I.e., the card delivers *decrypted* WEP packets, but leaves the WEP flag
  | set in the header, so that any analyzer that takes the WEP flag
  | seriously gets confused?
  | 
  | By "skip the WEP part of the packet" do you mean you skip the first 4
  | bytes after the header (i.e., the stuff dissected by the
  | 
  |   if (IS_WEP(COOK_FLAGS(fcf)))
  |     {
  |       int pkt_len = tvb_reported_length (tvb); 
  |       int cap_len = tvb_length (tvb);
  | 
  | 		...
  | 
  |     }
  | 
  | code in "dissect_ieee80211_common()"), and then, instead of calling
  | "call_dissector()", with "data_handle" as the handle argument, to
  | dissect the payload (minus the WEP header and the WEP CRC), you just
  | dissect that part of the frame as if it were unencrypted data?

  I got my laptop back and this is the "hack" I did:

  Index: packet-ieee80211.c
  ===================================================================
  RCS file: /cvsroot/ethereal/packet-ieee80211.c,v
  retrieving revision 1.53
  diff -c -r1.53 packet-ieee80211.c
  *** packet-ieee80211.c	2002/04/08 09:09:47	1.53
  --- packet-ieee80211.c	2002/06/12 16:51:00
  ***************
  *** 1521,1527 ****
    	  if (cap_len > 0 && pkt_len > 0)
    	    call_dissector(data_handle,tvb_new_subset(tvb, hdr_len + 4, -1,tvb_reported_length_remaining(tvb,hdr_len + 4)),pinfo, tree);
    	}
  - 	return;
        }
    
      /*
  --- 1521,1526 ----

  I did it a long time ago.  Basically I just let it fall into the part
  that does:
  	Now dissect the body of a non-WEP-encrypted frame.
  and life is good if I set the WEP key on the card.  Of course this
  is for WEP enscrypted packets.

  Doug A.

which is a bit less nice.

> Right now, the driver look for the AA AA 03 SNAP header in the payload; if
> it sees that, it clears the WEP bit.   It's not perfect, but it worked for
> me.  :) 

Does the driver know when the card is set to de-WEP the packets?  If it
does, and the card is set to de-WEP the packets, are *all* incoming
packets de-WEPed?

If so, perhaps the driver could clear the WEP bit iff the card is set to
de-WEP the packets.