ath: a few questions [really kismet and radiotap]

[Guy Harris]

> FWIW ethereal 
> deals with this issue by having a checkbox in the UI that you can use to 
> enable acceptance of such packets.

Actually, it controls whether to treat the last 4 bytes of the frame as
an FCS or not - the frames are accepted in either case, it would just
misdissect them in some fashion if the preference setting doesn't match
the capture.

> The radiotap format should have a flag to indicate FCS is included but 
> it never happened.  I will discuss this (again) with the radiotap-meister.

Actually, the *BPF header* should have several things, such as a
direction indication (incoming vs. outgoing at minimum, maybe with
"received unicast" vs. "received broadcast" vs. "received multicast" vs.
"received promiscuous" vs. "received somehow, I didn't bother to check"
as options for "incoming") and an FCS size indication (for the benefit
of PPP, as the FCS is, as I remember, negotiable).

802.11 isn't the only link-layer type where incoming frames might, or
might not, have an FCS - some Ethernet interfaces also supply it, at
least with some drivers (which is why I put the hack^H^H^Heuristic into
Ethereal to try to guess whether the last 4 bytes of the frame are an
FCS or not), and PPP frames might have them as well (depending on the
PPP driver for live captures; captures from Sniffers often have them,
probably because they're just doing passive captures), so an "FCS
present" indication needs to be generic for BPF.

At some point I need to look at BPF changes to support supplying that
additional information.  The next-generation libpcap format:

	http://www.tcpdump.org/pcap/pcap.html

should be able to handle that - records containing packets:

	http://www.tcpdump.org/pcap/pcap.html#sectionpb

can have options, including a flags option:

	http://www.tcpdump.org/pcap/pcap.html#appendixPBFM

with that information.  (Those records also include a count of packets
dropped since the last packet, which, if BPF is being changed, should
also be supplied.)

Obviously, the old header will have to be supported in BPF for backwards
compatibility; there'd probably be a BPF ioctl to request the new header.