Ethereal-dev: Re: [Ethereal-dev] Capturing from multiple interfaces, and why we need this.
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.
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.
> 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.
