I seem to be having all kinds of problems with tcpslice 1.2a1 (as obtained from the LBL FTP site. Due to a firewall I cannot get the CVS version of tcpslice.)
I am compiling on RedHat 7.1 x86 with all current updates. The first problem was a missing "#include <time.h>" needed in tcpslice.c and util.c. The next problem was a type mismatch in all the timeval structs. This one required a more aggressive fix-- all references to timeval were changed to "bpf_timeval" to match what is stored in the tcpdump header. This eliminated all the compile-time errors. I have patches available for both of these as well as source RPMs if anyone wishes to take a look at them. Unfortunately once I got it to compile, the run-time strangeness started. (Funny how that works...) The first problem was the error "problems finding end packet of file". The tcpdump files were created using tcpdump 3.6 (libpcap 0.6) on an HP-UX system. In order to eliminate this error I have to run them through tcpdump 3.4 (RedHat version 3.4-39 / libpcap 0.4-39) on my local system first. (i.e. "tcpdump -n -r <infile> -w <outfile>). For some reason tcpslice does not find a valid header anywhere near the end of the original file. (Endian problems on HP-UX PA-RISC versus Intel maybe?) Once that little problem is fixed the real interesting behavior begins. No matter what valid time range I chose, I would always end up with an output file of only 24 bytes. However, if I chose a time before the start time and did not specify an end time, I could get the whole file. I tracked this problem down to an apparent bug in tcpslice. In search.c the call "double full_span = timeval_diff( max_time, min_time)" should instead be "timeval_diff( min_time, max_time)" since this function subtracts the first parameter from the second, not the second from the first. I have a patch for this as well, and it's included in my source RPM for anyone who's interested. Once that was fixed I can now sometimes get valid packet trace slices. However, it seems to be very sensitive to the start time and/or duration chosen. Sometimes I get exactly what I wanted, other times I get my old friend the 24 byte file. It appears that perhaps the interpolation method fails to find the proper location sometimes, depending on exactly which timestamps it's looking for. Has anyone else had issues like this? It seems like I'm patching this thing an awful lot and I don't want to keep redoing someone else's work. Also, are there tarfiles of the CVS version of tcpslice available? Thanks for the help, -- Steve Bonds _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
