I've used tcpslice for many years (possible since its inception). Extremely useful utility. And despite having installed the latest as far as I can tell, this bug with large files still seems to exist.
Namely, you find yourself having to run tcpslice more than once with the same exact parameters in order to get the desired output file. So you take a 267gb 36 hour pcap file for example, and ask for a 2 minute period in that period. Then, instead of tcpslice giving you 2 minutes, it gives you a much larger amount (perhaps 20 minutes). (you can detect this by reading it through tcpdump) Then if you take the exact same parameters from the original tcpslice command and use them on the 20 minute generated file, you finally get your desired 2 min period. It is great that I've figured out the "double run" solution to get what I need, but I'm assuming tcpslice should be generating the proper 2 min period of time in the first run? *Example:* ======================================================== # ls -lat input.pcap -rw-r--r-- 1 root root 267323565734 Dec 17 12:14 input.pcap # /utils/bin/tcpslice_static 2017y12m15d12h5m 2017y12m15d12h7m input.pcap -w oop_really2.pcap # ls -lat oop_really2.pcap -rw-r--r-- 1 root root 3927053798 Dec 17 11:51 oop_really2.pcap ======================================================== *Hmm.....that file is still really big for only 2 minutes???* ======================================================== # tcpdump -nnn -r oop_really2.pcap | head -1 reading from file oop_really2.pcap, link-type EN10MB (Ethernet) 11:54:26.801029 IP # tcpdump -nnn -r oop_really2.pcap | tail -1 reading from file oop_really2.pcap, link-type EN10MB (Ethernet) 12:06:59.999907 IP ======================================================== *Yep -- it is beginning at hour 11 and 54 minutes....weird. At least it ends correctly.* *Well let's try that one more time, using the output of the previous as the input.* ======================================================== # /utils/bin/tcpslice_static 2017y12m15d12h5m 2017y12m15d12h7m oop_really2.pcap -w oop_really3.pcap # ls -lat oop_really3.pcap -rw-r--r-- 1 root root 487403473 Dec 17 12:03 oop_really3.pcap # tcpdump -nnn -r oop_really3.pcap | head -1 reading from file oop_really3.pcap, link-type EN10MB (Ethernet) 12:05:00.000557 IP # tcpdump -nnn -r oop_really3.pcap | tail -1 reading from file oop_really3.pcap, link-type EN10MB (Ethernet) 12:06:59.999907 IP ======================================================== *Nice! Only 487mb now. And it starts and ends as expected. But very mysterious. * ======================================================== tcpslice -r -d 2017y12m15d12h5m 2017y12m15d12h7m input.pcap -w oop_really2.pcap input.pcap Thu Dec 14 16:44:01 2017 Sat Dec 16 08:00:05 2017 start Fri Dec 15 12:05:00 2017 stop Fri Dec 15 12:07:00 2017 ======================================================== *Hmm -d doesn't seem to offer any clues. Shows what I wanted (the 2 minutes)* ======================================================== # tcpslice 2017y12m15d12h5m +2m input.pcap -w oop_really2.pcap # ls -lat oop_really2.pcap -rw-r--r-- 1 root root 3927053798 Dec 17 12:34 oop_really2.pcap ======================================================== *Ahh... too bad. Thought maybe differential timestamps might work better. (+2m)* _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
