Re: Building IPv6 code in tcpdump on systems without native IPv6 support

[Guy Harris <guy () alum mit edu>]

On Jul 21, 2004, at 4:39 AM, John Hawkinson wrote:

> Won't this have unfortunate effects on performance (and possibly 
> storage,
> but that's less concerning) for some people in borderline situations?

Only if they're running a version of tcpdump built without IPv6 
support.  The change wouldn't affect versions built with IPv6 support - 
the snapshot length has been 96 on them for a while now.

> First we break compatibility of the output format (do Van's awk scripts
> still even work?), next the behavior? Not very friendly...

The only way not to "break ... the behavior" at all is to make the CVS 
tree read-only.  The whole *point* of a change to a piece of software 
is to change its behavior in some sense.

The question is whether a *particular* behavior change causes problems 
that outweigh the benefits.  I'm not convinced that any performance or 
storage problems from boosting the default snapshot length for versions 
of tcpdump built on systems without native IPv6 support would be common 
enough, or severe enough, to outweigh the benefits of not having to 
worry about getting the "#ifdef INET6"s right (which they haven't been 
on a number of occasions - the platforms on which people are developing 
IPv6 stuff in tcpdump probably have IPv6 support, so people might write 
code that works fine there but not on v4-only systems, as they might 
not even have a v4-only OS on which to test it) or of having at least 
some support for dissecting v6-related packets even on systems that 
wouldn't generate or process those packets.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.