Re: tcptrace-bugs 6.6.1 bug with -e?

From: Shawn Ostermann (
Date: 06/29/04

Subject: Re: tcptrace-bugs 6.6.1 bug with -e? 
Date: Tue, 29 Jun 2004 15:07:25 -0400
From: Shawn Ostermann <>
Message-Id: <>


Stephen R Smoot <> wrote:

> Are there known problems with -e in 6.6.1?
> It usually works fine, but sometimes generates traces which have
> zillions of nulls at the end, so I suspect some length field is
> beign messed up somewhere.
> As an exampl, I did a tcpdump, then did a tcptrace -e and
> wc -c * => 8003460906 total
> whereas the orig tcpdump was 21766447 chars long,
> and if I look at the largest files, they have lots of nulls.

I seem to remember having some trouble with this once and thought that
it had been fixed. It's theoretically possible that it's correct,
because tcptrace just leaves NULLs in place of missing/truncated
segments (well, Unix does that from the seek()s).

Would it be possible to get a copy of the dump file that caused the problem?

> (PS as far as I can tell there are no graph/counters for concurrent
> tcp sessions open, am I missing something, or should I add it?)

The traffic module will do that. At least it did when I wrote it, but I
haven't used it in years.


tcptrace -xtraffic" -A -C -O -I"

for example (see tcptrace -hxargs)

Of course, if you can improve on that info, we'd love to see patches!


       Dr. Shawn Ostermann - EECS Department Chair - Ohio University
         330 Stocker Center, Ohio University, Athens, Ohio 45701-2979 -- FAX: (740)593-0007 -- Voice: (740)593-1566

This archive was generated by hypermail 2.1.7 : 06/30/04 EDT