Joerg Mayer wrote:
This just reminds me of something: When looking at a pcap file with WTAP_-
ENCAP_PRISM_HEADER it looks to me that there is always a CRC at the end, but
the detection doesn't work, so I always have to manually enforce interpre-
tation of CRC. When I looked at libpcap.c, it looked to me that it should
be able to automatically do the "right thing". What am I missing here?
The fact that for WTAP_ENCAP_PRISM_HEADER the libpcap code sets
"ieee_802_11.fcs_len" in the pseudo-header to -1, meaning "I don't know
whether there's an FCS at the end or not", not to 4, meaning "there's a
4-byte FCS at the end".
If the FCS len value is -1, the 802.11 dissector doesn't try to guess,
based on any lengths specified in protocols contained inside 802.11
(e.g., IPv4 or IPv6), whether the frame has an FCS, the way the Ethernet
dissector does - it just looks at the "Assume frames have an FCS" setting.
Has anyone different experience regarding my statement that prims captures
always have the CRC at the end?
I don't know whether either
1) all 802.11 devices for which the Linux driver supplies a Prism
header (I think there are at least some non-Prism devices for which the
driver generates a Prism header) can supply an FCS
or
2) all drivers for a given card that can supply an FCS configure it to
do so (the wonderful thing about Linux appears to be that you get a rich
choice of drivers for many cards - and that they don't necessarily
behave the same when it comes to packet capture, e.g. whether they
support monitor mode, how you put them into monitor mode if they do,
whether they provide a radio header, what type of radio header they
provide if they do, etc.)
so I wouldn't be surprised to find that some captures with a Prism
header have an FCS at the end and others don't - but I don't know
whether that's the case or not.
Are these all captures from the same type of card with the same driver?
It might be possible to use a heuristic similar to the one the Ethernet
driver uses, although there's no length field in management frames, so
the heuristic won't work for those frames unless the management frame
dissector does something such as checking whether, after dissecting the
fixed-length portion of the management frame or after dissecting any
tagged parameter after that, there are exactly 4 bytes remaining in the
reported length and, if so, sees whether there are tagged parameters in
that type of management frame (in the case where the check is done after
dissecting the fixed-length portion of the management frame) and if
those 4 bytes would be dissected as a valid tagged parameter (known tag
type byte, length byte with a value of 2 meaning 2 bytes of parameter
value) and, if so, assume the frame has no FCS, otherwise assume it does.