Ethereal-dev: RE: [Ethereal-dev] Capturing from multiple interfaces, and why we need this.
|From: Joerg Mayer
|
|On Mon, Feb 02, 2004 at 12:01:31PM -0800, Guy Harris wrote:
|> On Mon, Feb 02, 2004 at 01:59:43AM +0100, Joerg Mayer wrote:
|> > On Sun, Feb 01, 2004 at 04:24:55PM -0800, Guy Harris wrote:
|> > > One disadvantage of that solution is, of course, that
|> > > you'd only be able
|> > > to use it with versions of libpcap that support that
|> > > split of parsing and code generation.
|> >
|> > Actually, I'd prefer to just take the code and put it into
|> > wiretap, just
|> > as we are providing our own versions of vsnprintf etc in
|> > case they are missing.
|>
|> That's not the same - we provide "snprintf()" etc. only to
|> allow us to
|> use them on systems that lack them, not to provide an
|> "snprintf()" that has a particular minimum set of features.
|
|We will want to superimpose our own syntax on that code (the display
|filter syntax). Ideally, we would generate code as close as possible
|to the display filter syntax (just go up to the next supported level:
|e.g. if the filter syntax was dhcp, the resulting capture filter might
|be udp.port == 67 || udp.port == 68). Quite likely, we would offer
|dissectors to specify " replacement capture filters", i.e. a rule
|how to substitute a display filter with something the capture bdf
|engine can handle.
That's not as simple as it looks like. Ethereal display filters apply to
*any* occurrence of the named header or protocol, which can be tricky in
ip-over-ip and the likes. This implies that compiling a capture filter from
a display filter will not always return the same packets as when using a
display filter in Ethereal. The example you mention (dhcp <--> udp.port ==
67 or udp.port == 68) *must* imply 802.xyzzy/udp/ip for a capture filter.
Capture filters *assume* a lot in order to be efficient. For instance the
capture filter must map the filter expression to an offset and length within
the packet. Hence the default protocol stack assumptions have to be taken
into consideration. The typical example is the "port 1234" expression which
will be mapped to "the 1st or 2nd 16-bit value in the TCP or UDP header
equals 1234", requiring a computation of the IP header length (which not all
packet capture systems do: they sometimes ignore IPv4 options and assume a
20-byte IPv4 header).
If we want to provide useful capture filters, I am afraid we'd better offer
some default capture filters (cfilters file) anyway, and give them useful
and meaningful names.
|We may also want to support at least some older versions of libpcap
|or, to be more precise, some older versions of the bpf engine.
|
|> If we make our own copy of libpcap:
|>
|> When would we update it? When a new libpcap release comes out?
|> Whenever anything's checked into libpcap CVS? Whenever anything
|> interesting is checked into libpcap CVS? Etc..
|
|Just the way other "external" stuff like lemon, manuf, FAQ etc
|are handled:
|Whenever someone feels like doing the work, as long as
|backward compatibility is provided.
I am afraid that this inevitably results in time loss and duplicate effort.
|> What about WinPcap, which includes more stuff than just libpcap
|> - it includes drivers and a low-level library that's used by the
|> libpcap portion?
|
|Are we talking about different things? I'm not talking about
|the whole of
|libpcap: I'm only talking about the compiler.
|
|> Would developers understand that
|>
|> 1) It's BSD-licensed, not GPLed, and all changes to our
|> copy will be BSD-licensed?
|>
|> 2) Any improvements we make *WILL* be propagated to
|> tcpdump.org's libpcap?
|
|That should not be a problem: Other projects like the Linux kernel
|(and force contributors to) use a dual license, i.e. patches sub-
|mitted to certain files must be submitted with both licenses or they
|will not be committed. I would expect people who are able to code
|to be able to read too :-)
|
| Ciao
| Jörg
|--
|Joerg Mayer
|<jmayer@xxxxxxxxx>
|We are stuck with technology when what we really want is just
|stuff that
|works. Some say that should read Microsoft instead of technology.
|
|_______________________________________________
|Ethereal-dev mailing list
|Ethereal-dev@xxxxxxxxxxxx
|http://www.ethereal.com/mailman/listinfo/ethereal-dev
|
