Ethereal-dev: Re: [Ethereal-dev] Please review: Evaluating FCS bit in radiotap header

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, 16 Jun 2005 02:42:11 -0700
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.