Joerg Mayer wrote:
The attached patch should properly indicate whether a packet in radiotap
format has an fcs or not. As I a) don't have a sample capture and b) am
not sure I've uderstood the evalutation process during packet reading
correctly I'd be happy if someone could have a look at the patch before
it is committed.
...
+ wth->pseudo_header.ieee_802_11.fcs_len = 0;
+ /* IEEE80211_RADIOTAP_FCS = Bit 14, little endian */
+ if (*(buffer_start_ptr(wth->frame_buffer) + 5) & 64) {
+ wth->pseudo_header.ieee_802_11.fcs_len = 4;
+ }
At least according to the header file and the NetBSD checkin comment for
the change that added it:
revision 1.8
date: 2004/04/30 22:22:53; author: dyoung; state: Exp; lines: +8 -3
Sync with FreeBSD. Some apps get confused when the FCS comes at
the end of the tapped frame, so stick it into the radiotap header.
the FCS isn't at the end of the frame, it's in the radiotap header, so
you'd need to do a bit more - you'd have to scan the bitmask to see
which fields are present, in order to find out where the FCS field is in
the radiotap header, and then increase the size of the buffer by 4 bytes
and stick the FCS value at the end.
When the next-generation libpcap format is available, it might be worth
updating BPF to support it better; that would include adding to the BPF
header a flag field to contain various information, including the length
of the FCS (which, if 0, means "not present"), in which case the FCS
could be put at the end.
