This connection is probably your problem: . [10.252.95.13:0 <-> 10.119.58.167:0 ] : 1 connections : 0 bytes
tcpprep in the "auto" modes uses a weighted approach, and the 1 connection/0 bytes sounds likely to not be enough to trigger a definite decision. Using a lower --ratio value (say 1.0) may solve the problem depending on what's going on. On the other hand, you could just use the --port and --services options to split based on source/destination port. # cat >service.txt << EOF http tcp/80 kismet tcp/2005 EOF # tcpprep --port --services=service.txt -i my.pcap -o my.cache Regards, Aaron On 7/20/07, john mcnicholas <[EMAIL PROTECTED]> wrote: > Aaron, etc, > > fyi: as you suspected the latest build did fix the error: (msg was something > like;) "Um, shouldn't get here.". Thanks! > > Regarding the second error: > > this command: > > /usr/local/bin/tcpprep --minmask=24 --maxmask=16 --auto=router > --pcap= input.appcapture --cachefile=x.cache > > results with this: > > Error: unable to build a valid list of servers. Aborting. > > Here's some info on the capture file (and yes, i don't believe the > min/maxmasks played a factor) but tried it anyway: > > . 867 connections were found. > . 16 tier pairs were found. > . [10.119.61.1:0 <-> 10.252.96.16:0 ] : 31 connections : 427,159 > bytes > . [10.119.61.7:0 <-> 10.252.96.16:0 ] : 12 connections : 642,589 > bytes > . [10.119.57.12:0 <-> 10.252.96.16:0 ] : 23 connections : 472,319 > bytes > . [10.252.95.13:0 <-> 10.119.58.167:0 ] : 1 connections : 0 bytes > . [10.252.96.16:0 <-> 10.119.61.20:0 ] : 32 connections : 740,951 > bytes > . [10.252.96.16:0 <-> 10.119.61.24:0 ] : 18 connections : 507,330 > bytes > . [10.252.96.16:0 <-> 10.119.57.34:0 ] : 247 connections : 4,159,336 > bytes > . [10.252.96.16:0 <-> 10.119.61.47:0 ] : 23 connections : 842,232 > bytes > . [10.252.96.16:0 <-> 10.119.57.66:0 ] : 50 connections : 2,308,549 > bytes > . [10.252.96.16:0 <-> 10.119.57.71:0 ] : 41 connections : 677,771 > bytes > . [10.252.96.16:0 <-> 10.119.57.79:0 ] : 67 connections : 1,406,962 > bytes > . [10.252.96.16:0 <-> 10.119.57.81:0 ] : 20 connections : 1,061,113 > bytes > . [10.252.96.16:0 <-> 10.119.57.89:0 ] : 7 connections : 96,451 > bytes > . [10.252.96.16:0 <-> 10.119.63.102:0 ] : 141 connections : 2,366,090 > bytes > . [10.252.96.16:0 <-> 10.119.57.166:0 ] : 76 connections : 1,363,850 > bytes > . [10.252.96.16:0 <-> 10.119.57.173:0 ] : 78 connections : 2,361,052 > bytes > > Of the 867 connections all went to just 2 server ports: either 80 or 2005 > (kismet) > > Does anything seem suspicious? > > Initially, i thought the high number of duplicate timestamps might be > causing a problem, but a > subset of this trace without duplicates didn't change the output/behavior. > > Thanks again for your help. > > John > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Tcpreplay-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tcpreplay-users > > -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
