bug?

[Peter Van Epp]

> 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