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.
