timestamp bug SQUASHED

[Carter Bullard]

Gentle People,
I found a source of time corruption.  I believe (a.k.a. wish)
that it is our problem.  I have the fix on the server, even
now as I type.  Yes I know SQUASHED is a rather optimistic
term, but maybe just maybe it might apply here ;o)

ftp://qosient.com/dev/argus/argus-2.0/argus-2.0.0i.tar.gz

I did fix some problems in tcp RESET handling, however,
I'm not confident that it will fix Russell's problem, but
maybe just maybe .......

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 17A
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
Sent: Wednesday, September 27, 2000 11:06 AM
To: argus
Subject: Re: bug?


> Hey Peter,
>    It' complaining that it can't generate a listen on
> port 561.  Use the -P 0 option to disable the listen,
> or set it to another port.
>
>    Any chance you can test running a single argus
> against two interfaces, with multiple -i options?

	Yep, I should be able to do that. Both test machines have dual
interfaces and while I haven't tried it yet I expect two copies of tcpreplay
will happily coexist on two interfaces, and capturing through a Shomiti from
a fdx link into two copies of tcpdump should give me appropriate traffic
files to play with. Synchronization may be a bit exciting though (seeing the
ack before the packet is sent is apt to cause excitement!). It may be
necessary
to modify tcpreplay to deal with full duplex properly (i.e. read two tcpdump
files and order their time stamps and interfaces in the correct order to
properly simulate the real link so we don't have the ack before packet
problem.)

>
>    Time stamp problems still?  I'll start poking
> around.

	It looks like it is an equal oppertunity bug, it seems to get mostly
tcp packets but also unknowns (probably less because there are less of
them):

Tue 09/26 19:36:24.375483  ipx   0:6:29:29:62:d9       ->
0:90:27:9c:33:37
  3        0         582          0           INT
Tue 09/26 20:33:47.656973   tcp    142.58.181.4.8080   ->
24.113.11.50.1046
  3        5         913          134         FIN
Sun 02/18 03:22:28.456000768  unkn  0:1:2:44:d4:a8        ->
0:50:da:93:0:5e
     2271     0         104466       0           TIM
Tue 09/26 18:40:15.444643  unkn  0:0:89:3:1d:c0        ->
0:0:f8:4f:e3:d2
  3        0         138          0           INT
Tue 09/26 18:40:15.443950  unkn  0:0:89:3:1d:c0        ->
9:0:7:0:0:45
  3        0         138          0           INT
...
Tue 09/26 20:34:06.177178   tcp    142.58.181.4.8080  <?>
24.113.11.50.1054
  2        3         635          82          EST
Sat 02/17 15:25:45.1428488704   tcp   142.58.225.18.46190 <o>
24.115.76.225.
6000  3961     3695      2228760      187840      TIM
Tue 09/26 19:36:18.364103  ipx   0:90:27:55:20:4d      ->
ff:ff:ff:ff:ff:ff
  58       0         4640         0           INT

	As I said I'll try and get to pushing a tcpdump capture back at argus
at various speeds with tcpreplay and see if I can reproduce the corruption
and see if it is speed related. It may be traffic peaks that are causing it
somehow. I have a dump file that I played back at our sniffer to get packet
counts so I can check the counts.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000927/8becbc0d/attachment.html>