> The note doesn't mention if the new tcpdump somehow modifieds
> the libpcap format to save interface info, but the text output
> for tcpdump in RH 6.1 has changed.
>
> http://lwn.net/1999/1014/a/rh6-tcpdump.html
Well, I grabbed the SRPM for RH 6.1's "tcpdump"; it contained "tar"
files of "libpcap-0.4" and "tcpdump-3.4", as well as a pile of patch
files, the biggest of which appear to be the "ss990417" patches from
http://ftp.sunet.se/pub/os/Linux/ip-routing/lbl-tools/
The patch to "libpcap" changes "pcap_pkthdr" to
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
#ifdef linux
int ifindex;
unsigned short protocol;
unsigned char pkt_type;
#endif
};
but, of course, they don't put any change into the version number in the
header of the file, so it's not clear whether the RH 6.1 "tcpdump" - or
any other program built with the RH 6.1 "libpcap" - can
1) read anybody else's "tcpdump" files
or
2) write "tcpdump" files that any other "tcpdump" can read
although I seem to remember being rudely surprised by the "tcpdump"
bundled with Digital UNIX also having some incompatible file format
change, so perhaps they're not the only people to cheerfully "improve"
things in an incompatible fashion.
Oh, and it still has a "struct timeval" at the beginning, so you still
get screwed if you write the capture file on a machine with one size for
"tv_sec" and "tv_usec" and try to read it on a machine with another size
- the patch does *NOT* touch "savefile.c", so it doesn't address those
problems at all.
"But surely nobody ever captures on one machine and wants to read it on
another machine, so this isn't a problem, right?"
Sigh. All the more reason to want to get Wiretap to the point that it
can do all that "libpcap" can, and give it its own capture file format,
and try to keep people from going off and privately "improving" it
incompatibly.
