Date: Tue, 15 Jan 2002 09:41:48 -0500 (EST) From: Avinash Lakhiani <alakhian@masaka.cs.ohiou.edu> Subject: Re: Andreas Hasenack: Fatal, too many hosts to name (max length 8) Message-ID: <Pine.GSO.4.10.10201150937100.10767-100000@vger>
Andreas,
There's nothing wrong with the tcpdump data. You're
running up against a tcptrace limit that is confusing me, though. The
program wants to "name" each host pair. The first in a2b, then c2d,
etc... zzy2zzz, etc. Those names are used in the textual output and
as the names of the files that it can create. The length of those
names is supposed to be limited to 8 characters, which my comment in
plotter.c:HostLetter() says should "limit" you to 209Billion hosts per
file. I don't imagine you're facing that limitation, so something
else must be happening.
My first suggestion, if you're up for it, is to do a little debugging
in the HostLetter function (it's short) to show you what is going
wrong. If you're not comfortable doing that, could you please put a
copy of your binary input file someplace that we can get to it and
then send us a pointer. Then I can have one of our students find the
problem. It's very puzzling... (--sdo)
--On behalf of Dr. Ostermann
--Avinash.
~ From: Andreas Hasenack <andreas@conectiva.com.br>
~ To: tcptrace-bugs@tcptrace.org
~ Subject: Fatal, too many hosts to name (max length 8)
~
~ [root@pandora /root]# tcpdump -r output -n
~ 14:21:59.167867 216.10.32.10.6667 > 10.0.17.30.1190: P 2087429120:2087429207(87) ack 2103271664 win 32120 <nop,nop,timestamp 603715307 44226095> (DF)
~ 14:21:59.167918 10.0.17.30.1190 > 216.10.32.10.6667: . ack 87 win 17376 <nop,nop,timestamp 44227426 603715307> (DF)
~ 14:22:07.887348 10.0.17.30.1190 > 216.10.32.10.6667: P 1:21(20) ack 87 win 17376 <nop,nop,timestamp 44228298 603715307> (DF)
~ 14:22:08.024652 216.10.32.10.6667 > 10.0.17.30.1190: P 87:164(77) ack 1 win 32120 <nop,nop,timestamp 603716193 44227426> (DF)
~ 14:22:08.024699 10.0.17.30.1190 > 216.10.32.10.6667: . ack 164 win 17376 <nop,nop,timestamp 44228311 603716193> (DF)
~ 14:22:08.494394 216.10.32.10.6667 > 10.0.17.30.1190: . ack 21 win 32120 <nop,nop,timestamp 603716241 44228298> (DF)
~ 14:22:08.799260 216.10.32.10.6667 > 10.0.17.30.1190: P 164:287(123) ack 21 win 32120 <nop,nop,timestamp 603716266 44228311> (DF)
~ 14:22:08.799310 10.0.17.30.1190 > 216.10.32.10.6667: . ack 287 win 17376 <nop,nop,timestamp 44228389 603716266> (DF)
~ 14:22:18.505189 216.10.32.10.6667 > 10.0.17.30.1190: P 287:352(65) ack 21 win 32120 <nop,nop,timestamp 603717241 44228389> (DF)
~ 14:22:18.505252 10.0.17.30.1190 > 216.10.32.10.6667: . ack 352 win 17376 <nop,nop,timestamp 44229359 603717241> (DF)
~
~ It works with [t]ethereal as well, but tcptrace doesn't like it:
~ [root@pandora /root]# tcptrace output
~ 1 arg remaining, starting with 'output'
~ Ostermann's tcptrace -- version 6.0.1 -- Mon Dec 3, 2001
~
~ Fatal, too many hosts to name (max length 8)
~
~ I read in the mailing archives that another user had this problem too, but found
~ no solution.
~
~ Any clues?
~
~
~ - --liOOAslEiF7prFVr
~ Content-Type: application/octet-stream
~ Content-Disposition: attachment; filename=output
~ Content-Transfer-Encoding: base64
~
~ 1MOyoQIABAAAAAAAAAAAAGAAAAABAAAApzMzPLuPAgBgAAAAmQAAAABQ2nK8lwDA3wJb8wgA
~ RQAAi546QAAzBpYA2AogCgoAER4aCwSmfGukAH1dYPCAGH14tuYAAAEBCAoj+/brAqLWLzpi
~ cnVkZXIhfnNlcmdpb0AyLTA0MS5jdGFtZTcwMaczMzzujwIAQgAAAEIAAAAAwN8CW/MAUNpy
~ vJcIAEUAADT+1kAAQAYouwoAER7YCiAKBKYaC31dYPB8a6RXgBBD4Aj9AAABAQgKAqLbYiP7
~ 9uuvMzM8NIoNAFYAAABWAAAAAMDfAlvzAFDacryXCABFAABI/tdAAEAGKKYKABEe2AogCgSm
~ Ggt9XWDwfGukV4AYQ+D5PgAAAQEICgKi3soj+/brUElORyBMQUcyNzM4MDM2NjMzDQqwMzM8
~ TGAAAGAAAACPAAAAAFDacryXAMDfAlvzCABFAACBqqZAADMGiZ7YCiAKCgARHhoLBKZ8a6RX
~ fV1g8IAYfXjEXgAAAQEICiP7+mECottiOmJydWRlciF+c2VyZ2lvQDItMDQxLmN0YW1lNzAx
~ sDMzPHtgAABCAAAAQgAAAADA3wJb8wBQ2nK8lwgARQAANP7YQABABii5CgARHtgKIAoEphoL
~ fV1hBHxrpKSAEEPgAbEAAAEBCAoCot7XI/v6YbAzMzw6iwcAQgAAAEIAAAAAUNpyvJcAwN8C
~ W/MIAEUAADSrNUAAMwaJXNgKIAoKABEeGgsEpnxrpKR9XWEEgBB9eMf1AAABAQgKI/v6kQKi
~ 3sqwMzM8HDIMAGAAAAC9AAAAAFDacryXAMDfAlvzCABFAACvq6FAADMGiHXYCiAKCgARHhoL
~ BKZ8a6SkfV1hBIAYfXhsbwAAAQEICiP7+qoCot7XOmVsaXBoYXMhfmVsaXBoYXNAMjAwLjIy
~ My42My43sDMzPE4yDABCAAAAQgAAAADA3wJb8wBQ2nK8lwgARQAANP7ZQABABii4CgARHtgK
~ IAoEphoLfV1hBHxrpR+AEEPgAJ8AAAEBCAoCot8lI/v6qrozMzxltQcAYAAAAIMAAAAAUNpy
~ vJcAwN8CW/MIAEUAAHW3ZkAAMwZ86tgKIAoKABEeGgsEpnxrpR99XWEEgBh9eAxpAAABAQgK
~ I/v+eQKi3yU6Z3dtIX5nd21AMi0wNDEuY3RhbWU3MDEtNS50ZWy6MzM8pLUHAEIAAABCAAAA
~ AMDfAlvzAFDacryXCABFAAA0/tpAAEAGKLcKABEe2AogCgSmGgt9XWEEfGulYIAQQ+D4xAAA
~ AQEICgKi4u8j+/55
~
~ - --liOOAslEiF7prFVr--
~
~ ------- End of Forwarded Message
~
~
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 01/15/02 EST