On Tue, 5 Jun 2001, Guy Harris wrote:
> > 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?
Yes. The most common length is 24 bytes. If there aren't any bridges in
the network, all data (not control) frames should be that length. After
that there is a 802.2 LLC header, where may be a link type (this is usually
the case). Should I set off_nl = 24; off_linktype = -1; ? Anyway, if WEP
(encryption) is being used, the 802.2 header won't be visible. What do you
think of all this?
Javier Achirica
-
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
