> On Tue, 5 Jun 2001, Bill Fenner wrote:
>
> > Well, it'd be nice to at least set off_linktype and off_nl correctly
> > so that libpcap could filter when the 802.11 header is included too.
>
> Yes, the problem with 802.11 is that it is a variable length header, so it
> may change in each packet. I haven't found a way that could make it work.
> Do you have any suggestion?
Unfortunately, whilst the BPF machine language can do that by saving the
link-layer header length in a variable (so that it can handle
expressions that test both fields in headers past the link-layer header
*and* headers past the also-variable-length IP header *and*, for
example, test the IP header, the TCP header, and then the IP header
again), I'm not sure the current code generator makes that easy;
something along the lines of the BPF+ code generator, which, as I
remember, generates code in SSA form and then later does register
assignments (so that it'd be easier to put spill/fill code in, I
suspect), might work better.
Currently, we also have that problem for token ring, which we "solve" by
punting on source-routed frames - we just assume that there's no source
routing. Is there a "typical" length for 802.11 headers on data frames,
so that you can at least generate code that works most of the time, even
if it doesn't work all the time?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
