Date: Wed, 26 Jan 2005 21:28:23 -0800 From: Guy Harris <guy@alum.mit.edu> To: sam@errno.com Cc: freebsd-mobile@freebsd.org Subject: Re: ath: a few questions [really kismet and radiotap] Message-ID: <41F87BF7.8000008@alum.mit.edu>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F87BF7.8000008>