On Fri, Nov 01, 2002 at 05:34:42PM -0500, Solomon Peachy wrote: > Once upon a time, the linux-wlan-ng driver had this "monitor mode' which > included a special "sniff header". That's in ethereal as packet-prism.c. > As time went on, more people started using this header. And it's > relatively well used now. > > Unfortunately, it's rather inefficient, and time and needs move on, so > here's our second attempt at a sniff header. It has more relevant data, > applies to 802.11a/b/g, and is more compact. > > For a full writeup of the format, see: > > http://www.shaftnet.org/~pizza/software/capturefrm.txt It would be nice if this were adopted by drivers other than the linux-wlan-ng drivers, e.g. the Aironet drivers for Linux, and various BSD drivers. The variable-length sniff header can, in principle, be handled by BPF, as it doesn't have to be parsed by a loop (which BPF cannot handle, unless you completely unroll the loop - *if* that's possible), although the *current* BPF compiler can only handle variable-length IP headers, not variable-length link-layer or sniff headers. One of these days I may do something about that, so that one could filter captures when using tcpdump, Ethereal, etc.. I also seem to remember seeing in some of Doug Ambrisko's code for the Aironet cards on FreeBSD something that might be the physical layer convergence protocol header - but I haven't yet set up a wireless network at home, so I can't check that out with my shiny new Aironet card, and don't have the 802.11 or 802.11b spec handy to check whether that's what it is. > Incidentally, proto_tree_add_uint doesn't handle uint64, nor is there a > tvb_get_ntouint64 equivalent. No, but: 1) "proto_tree_add_item()" can handle it, with FT_UINT64; 2) there are routines declared in "epan/int-64bit.h" to handle 64-bit integers without requiring compiler support (which, on at least one platform on which people have built Ethereal, is not available with the compiler that comes with the OS - yes, GCC might work on it, but...).
Powered by MHonArc 2.6.10