Wireshark · Ethereal-dev: Re: [Ethereal-dev] [PATCH] updated 802.11 dissector

[Solomon Peachy <solomon@xxxxxxxxxxxxxx>]

On Mon, Jun 17, 2002 at 12:20:25PM -0700, Guy Harris wrote:
> But it *does* vary on a per capture file type basis!  That preference
> should be completely ignored when reading an AiroPeek or Wireless
> Sniffer file, as those files appear *never* to contain the FCS at the
> end of the frame.

Of course it can vary on a per-file basis!  My point was that it won't
change in the middle of a capture on a per-packet basis, if you're
capturing the whole frame.  

> I.e, don't assume that libpcap is the only source of 802.11 captures
> read by Ethereal.

I assumed absoultely nothing -- I wrote generic code that can handle
the FCS being present or not, configurable via user input.  

What we're talking about here is adding extra intelligence in the
dissector to automagically detect the FCS's presence (or lack thereof in
this case)  

I reiterate -- the pref defaults to "FCS not present".  This results in
behaivor identical to the unpatched dissector.  It breaks nothing.
(that wasn't already broken...)

> No, it should have an "FCS present" flag as an argument.  For
> "dissect_ieee80211()", the toggle should be passed as an argument; for
> "dissect_ieee80211_radio()", FALSE should, for now, be passed as an
> argument, *not* the toggle, as the toggle should have no effect
> whatsoever on the processing of AiroPeek or Wireless Sniffer captures.

So the FCS "toggle" has three states:

1) FCS is _not_ present (ie via dissect_ieee80211_radio())
2) FCS is _always_ present
3) FCS status unknown, use pref.

The code I have right now handles (1) and (3), as there's nothing in the
wild that requires (2) yet.. that we have any way of detecting, that is.

> The WEP ICV comes *before* the payload, so if it's not present, the
> payload also isn't present, right?

WEP slaps a four-byte header at the beginning of the payload, and another
four bytes at the end.  The first four bytes contain the 3-byte IV, plus
the key ID and some padding.  The latter four bytes (ICV) are essentially
a CRC to verify the payload was decoded correctly.

Version four of the patch is up at the usual place.  

 - Pizza
-- 
Solomon Peachy                        solomon@xxxxxxxxxxxxxx
AbsoluteValue Systems                 http://www.linux-wlan.com
715-D North Drive                     +1 (321) 259-0737  (office)
Melbourne, FL 32934                   +1 (321) 259-0286  (fax)

Attachment: pgpJqkH8u8EJ9.pgp
Description: PGP signature