On Fri, Nov 01, 2002 at 02:49:15PM -0800, Guy Harris wrote:
> > 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.
That's sort of what happened with the old "prism" header. But for the
most part, people just use a standard 802.11 header on captures, and
forego any fancy link-layer details that these headers provice. Most
people don't care about anything beyond 802.11.
I've already started passing it around to people I know, and the next
step is to pass it on to the maintainers of the other drivers.. I
certianly share your desire to see it become the standard "extra crap"
header on 802.11 sniffs. We've tried to make it as useful as possible,
and there is a mechanism for extending it via the version/length fields.
This header will eventually be used in commercial products regardless of
other driver adoption though.
> 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..
This sort of thing is necessary for 802.11 proper, with the A3/A4 header
variation, to say nothing about sniff headers.
> 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.
I'll have a look at it, thanks. Unfortunately, the "PLCP header" is
rarely exposed by the hardware, and those that expose it tend to only
expose certian bits. And PLCP is too closely tied with the underlying
transport anyway. :)
> 1) "proto_tree_add_item()" can handle it, with FT_UINT64;
Neat! I'll use this in the next revision.
- Pizza
--
Solomon Peachy solomon@xxxxxxxxxxxxxx
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
Attachment:
pgpprKTwYvi90.pgp
Description: PGP signature