problem experienced with ra client: unequal results
carter at qosient.com
carter at qosient.com
Fri Jul 6 09:28:42 EDT 2007
Yes, as I suspected. Probably a compiler struct padding issue, or an alignment problem, and the power pc isn't complaining!!! This helps even more!!!
Carter
Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
-----Original Message-----
From: Peter Van Epp <vanepp at sfu.ca>
Date: Thu, 5 Jul 2007 14:41:55
To:argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] problem experienced with ra client: unequal results
On Wed, Jul 04, 2007 at 03:22:32PM +0000, carter at qosient.com wrote:
> Hey R?al,
> Peter is right, we do have a little instability with the release candidates, and I've been extremely busy on real work, so, ...., my fault at not getting the fixes out quickly!!
>
> The zero length record is a persistent problem, and I still do not have enough data to fix it properly. If you can share platform, strategy (radium?) and 64-bit vs 32-bit info and of course a sample data file that causes the error, that would go a long way to fixing the problem.
>
A data point on this one:
FreeBSD 6.2 on a 32 bit Intel:
07-07-05 14:07:42 e tcp 142.58.51.17.49680 -> 65.54.171.26.1863 2 2 120 508 CON
07-07-05 14:07:42 e udp 72.24.222.42.10605 -> 142.58.51.152.19879 1 0 314 0 INT
07-07-05 14:07:42 e udp 68.150.54.174.1095 -> 206.12.16.222.137 1 0 92 0 INT
07-07-05 14:07:42 e d tcp 192.75.241.56.3932 -> 207.46.1.81.80 4 3 1573 935 CON
07-07-05 14:07:42 e tcp 142.58.74.225.1960 -> 208.111.129.38.80 8 8 1420 2656 FIN
07-07-05 14:07:42 e tcp 142.58.51.152.19879 -> 219.142.130.91.2061 1 0 60 0 FIN
07-07-05 14:07:42 e icmp 206.12.16.134 -> 58.245.75.154 1 0 98 0 ECO
07-07-05 14:07:42 e d tcp 142.58.83.7.4755 -> 203.188.205.191.80 4 2 866 312 CON
07-07-05 14:07:42 e udp 209.193.22.238.11821 -> 142.58.65.30.13792 1 0 104 0 INT
07-07-05 14:07:42 e udp 67.70.110.88.13075 -> 142.58.67.230.8519 1 0 140 0 INT
07-07-05 14:07:42 e icmp 206.12.16.134 -> 203.211.83.124 1 0 98 0 ECO
07-07-05 14:07:42 e d tcp 142.58.211.84.33916 -> 216.200.62.206.80 5 5 796 467 FIN
And a Mac OS 10.4 box 64 bit PPC reading from the same argus sensor
(which exhibits the 0 length problem):
07-07-05 14:07:42 e tcp 142.58.51.17.49680 -> 65.54.171.26.1863 2 2 120 508 CON
07-07-05 14:07:42 e udp 72.24.222.42.10605 -> 142.58.51.152.19879 1 0 314 0 INT
07-07-05 14:07:42 e udp 68.150.54.174.1095 -> 206.12.16.222.137 1 0 92 0 INT
07-07-05 14:07:42 e d tcp 192.75.241.56.3932 -> 207.46.1.81.80 4 3 1573 935 CON
07-07-05 14:07:42 e tcp 142.58.74.225.1960 -> 208.111.129.38.80 8 8 1420 2656 FIN
07-07-05 14:07:42 e tcp 142.58.51.152.19879 -> 219.142.130.91.2061 1 0 60 0 FIN
07-07-05 14:07:42 e icmp 206.12.16.134 -> 58.245.75.154 1 0 98 0 ECO
07-07-05 14:07:42 e d tcp 142.58.83.7.4755 -> 203.188.205.191.80 4 2 866 312 CON
07-07-05 14:07:42 e udp 209.193.22.238.11821 -> 142.58.65.30.13792 1 0 104 0 INT
07-07-05 14:07:42 e udp 67.70.110.88.13075 -> 142.58.67.230.8519 1 0 140 0 INT
ra3[21413]: 07-07-05 14:27:09 ArgusReadStreamSocket (0x617fa4) record length is zero
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
More information about the argus
mailing list