TCP tools.
k claffy
kc at caida.org
Sat Jul 17 00:08:41 UTC 1999
forrest
http://www.caida.org/Tools/taxonomy.html
suggests that the closest you can get right now
is creative combination of tcpdump, tcptrace and xplot.
tcpdump ftp://ftp.ee.lbl.gov/
tcptrace http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html
xplot ftp://mercury.lcs.mit.edu/pub/shep/
if there is a free package that does everything
including diagnosing the problem, we havent found it yet.
(good windmill, tho.)
if you need tcpdump at or above OC-3,
you'll need something like
http://www.caida.org/Tools/Coral/
(not yet for the faint of heart)
also
http://www.psc.edu/networking/tcp_friendly.html
http://www.psc.edu/networking/perf_tune.html
might be of interest to you in vendor.appeals
sorry the news isn't better
maybe give it some time
(actually, give it some coders)
k
On Fri, Jul 16, 1999 at 03:36:35AM -0600, Forrest W. Christian wrote:
I really can't think of a better place to ask this, so If anyone has any
ideas of a place better suited please let me know (no flames please).
I'm looking for a (free or quite inexpensive) tool to help diagnose some
bizzare TCP problems we're having with some TCP flows stalling exactly 32k
into the transfer. This isn't the same file and it's almost exacly 32k
each time... but I digress.
Is there a tool out there that can sniff a TCP flow and do some basic
analysis such as missed acks, duplicate packets, Window Sizes, etc. etc.
Mainly, I'm looking at something which can compare what it sees with some
semblance of a normal flow and pick out "errors". Other tools to track
down stalls would be helpful also. No, I'm not looking for ping tools or
flood tools, etc., but instead something which can help me determine why
this particular TCP implementation is stalling consistently in serveral
different environments so I can go yell at the vendor.
I realize that most if not all packet sniffers will provide the
information neccessary to do this analysis by hand, but picking apart
multiple flows bit by bit can be tedious and error prone, and not
something I particularly want to do if there is an easier way.
Thanks for all pointers.
- Forrest W. Christian (forrestc at imach.com) KD7EHZ
----------------------------------------------------------------------
iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com
Solutions for your high-tech problems. (406)-442-6648
----------------------------------------------------------------------
More information about the NANOG
mailing list