On Wed, Jun 12, 2002 at 10:15:35AM -0700, Doug Ambrisko wrote:
> Huh, I don't see anything strange with it? The beacons look fine
> except when there are typical RF collisions that mangle packets.
>
> http://www.ambrisko.com:/doug/an/doug.jpg
Which version of Ethereal are you using?
Ethereal's 802.11 dissector used to, in effect, ignore the last 4 bytes
of a packet when dissecting the tagged parameters of an 802.11
management frame; however, that "worked" only when the 802.11 frame had
4 extra bytes of junk (or FCS?) at the end, but didn't work with, for
example, capture files from AiroPeek or Wireless Sniffer.
I checked in a fix for that in Ethereal 0.9.2.
Unfortunately, the fix for that means that management frames (or any
other frames that don't have a length elsewhere in the frame as, for
example, IP packets do) may be misdissected, as the extra 4 bytes may
get dissected as frame data. If you're running a version of Ethereal
before 0.9.2, that might explain why you're not seeing the "Malformed
Packet" errors on the beacon frames.
Solomon Peachy said, in another message, that one change he'd made to
the 802.11 dissector was to make it
3) Properly identify the FCS at the end of an 802.11 frame.
- actually, this will require it to be present -- according to the
802.11 spec, it should be there. Some wireless cards pass it down,
and if they don't, the driver is broken. *grin*
That change would presumably prevent the misdissection of junk at the
end of the frame (the 05 04 02 03 at the end); unfortunately, it'd also
mean that we'd throw away the last 4 bytes at the end of the AiroPeek
and Wireless Sniffer captures.
In addition, I'm not sure what it'd do to *outgoing* packets, if any of
the BSD or Linux drivers support networking operation while you're in
monitor mode (or support transmission of raw packets via BPF or a
PF_PACKET socket) so that there *are* outgoing packets while you're
sniffing.
If all wireless cards supply the FCS when in monitor mode, and either
there'll never be outgoing packets *or* the driver, when the card is in
monitor mode, puts 4 bytes of stuff at the end of outgoing packets
before handing them to the "bpf_*tap" routine or to the "send a packet"
routine in Linux (so that both incoming and outgoing packets will have
those 4 bytes at the end), then the right fix for this probably involves
adding a "has_fcs" gboolean argument to
"dissect_ieee80211_common()", and having it dissect an FCS at
the end only if "has_fcs" is TRUE;
having "dissect_ieee80211()" pass TRUE as the "has_fcs" argument
and having "dissect_ieee80211_radio()" pass FALSE as "has_fcs".
If, however, not all wireless cards supply the FCS when in monitor mode
(I presume the cards that do include the cards supported by the wlan-ng
Prism II driver, as well as the Aironet cards; I don't know about the
Orinoco cards, and I think the Linux Orinoco driver doesn't support
monitor mode with the 8.0 firmware version of the Orinoco cards), that
might require adding a new DLT_IEEE802_11_NOFCS value or something such
as that.
