> 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.
