Redhat 6 (glibc 2.1) uses a time_t (long int) for the struct timeval
members.
In redhat 6, libpcap is exacly as you describe below, full of 64-bit bugs.
I think the best thing to to is fix libpcap to correctly handle any length
int, by defining macros SWAP16, SWAP32, and SWAP64, and just do a sizeof
check to see which one should be used.
As to my previous comment about not using 64-bit values for timestamps so
that other architechtures could read file generated on 64-bit
architectures, I was completely wrong. This stuf is full of
arch-dependent stuff anyway.
On Sun, 8 Aug 1999, Guy Harris wrote:
> > I'm running linux-2.2.10, redhat-5.2 on an alpha. With the 2.2-series
> > kernel on alpha, the seconds and microseconds are stored as 64-bit
> > integers instead of 32-bit integers. This is a nasty little problem I ran
> > into with the stock tcpdump/libpcap in the stock redhat-5.2/alpha (glibc
> > 2.0). The headers that come with redhat define a timestamp as two 32-bit
> > ints, and this causes all sorts of nastyness. I got it to work by
> > building libpcap/tcpdump after changing the struct timeval in timebits.h
> > to look like the one in the kernel. I beleive RedHat have made this same
> > change as of 6.0 (glibc 2.1).
>
> Could somebody please check on that?
>
> In particular, could somebody please see what "pcap.h", in the source to
> the "libpcap" library for *any* Alpha Linux distribution, defines
> "struct pcap_pkthdr" as?
>
> The "libpcap" library as it comes from LBL defines it as:
>
> 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) */
> };
>
> However, "savefile.c" byte-swaps it with
>
> hdr->ts.tv_sec = SWAPLONG(hdr->ts.tv_sec);
> hdr->ts.tv_usec = SWAPLONG(hdr->ts.tv_usec);
>
> and, as "SWAPLONG" is defined in "savefile.c" as:
>
> #define SWAPLONG(y) \
> ((((y)&0xff)<<24) | (((y)&0xff00)<<8) | (((y)&0xff0000)>>8) | (((y)>>24)&0xff))
>
> that's not going to work very well at all.
>
> Or, to put it another way, the code as it comes from LBL has wired
> rather firmly into it the notion that the members of a "struct timeval"
> are 32-bit integral quantities; it simply won't do the right thing if
> that's not true.
>
-John
