Aironet/Cisco cards won't supply the FCS to the OS even in monitor mode.
There's a bit in the header signalling if the FCS didn't match, but frames
with incorrect FCS in most cases won't be supplied to the OS anyway.
I don't know if there's an undocumented flag somewhere to change that
behaviour.
Javier Achirica
On Wed, 12 Jun 2002, Guy Harris wrote:
> 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.
>
>
