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...).