[Fwd: Re: [ARGUS] Peculiar cross platform argus/ra non-interoperability]

[Michael J. Slifcak]

Start where Joe wrote something is hosed.

Summary:  change   int cnt = read(...)   to ssize_t cnt = read(...)
and review write() usage, too.

Joe Christy wrote:
> -------- Original Message --------
> From: - Sun Aug 08 16:21:38 2004
> Message-ID: <4116B581.4030705 at eshu.net>
> Date: Sun, 08 Aug 2004 16:21:37 -0700
> From: Joe Christy <joe at eshu.net>
> User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040704)
> MIME-Version: 1.0
> To: Peter Van Epp <vanepp at sfu.ca>
> Subject: Re: [ARGUS] Peculiar cross platform  argus/ra non-interoperability
> References: <411664D1.3040207 at eshu.net> <20040808192330.GA6451 at sfu.ca>
> In-Reply-To: <20040808192330.GA6451 at sfu.ca>
> 
>   Vis-a-vis Peter's note of 08/08/2004 12:23 PM:
> 
>>     Nothing springs to mind as likely wrong. I'd guess the best bet is to
>> touch .devel and .debug in the linux argus source directory, re run 
>> configure and make clean; make to get a debug copy of ra. Then start 
>> the ra with a -D8 or so (which dumps debug messages to the console) to 
>> see where it dies which should give a clue as to why.
>> ...
> 
> 
> Well, now that I've enabled debug output on both ends, I see:
> 
> On Monitoring Station:
> ra -a -D8 -S 172.24.4.1
> ra[17146]: 04-08-08 15:21:31.6825 ArgusFree (0x97b5604) returning
> ra[17146]: 04-08-08 15:21:31.6826 ArgusDeleteHostList () returning
> ra[17146]: 04-08-08 15:21:31.6838 ArgusCalloc (1, 496) returning 0x97b5604
> ra[17146]: 04-08-08 15:21:31.6839 ArgusAddHostList (elegba.eshu.net, 1)
> returning 1
> ra[17146]: 04-08-08 15:21:31.6844 ArgusFilterCompile () waiting for
> filter process 17147 on pipe 4
> ra[17147]: 04-08-08 15:21:31.6847 ArgusFilterCompile () returning
> ra[17146]: 04-08-08 15:21:31.6850 ArgusFilterCompile () read filter 
> length 1
> ra[17146]: 04-08-08 15:21:31.6851 ArgusFilterCompile () read filter body 8
> ra[17146]: 04-08-08 15:21:31.6851 ArgusFilterCompile () returning 0
> ra[17146]: 04-08-08 15:21:31.6865 Trying eshu.eshu.net port 561
> Expecting Argus records
> ra[17146]: 04-08-08 15:21:31.6869 connected
> ra[17146]: 04-08-08 15:21:31.6870 ArgusGetServerSocket (0x97b5604)
> returning 4
> ra[17146]: 04-08-08 15:21:31.6976 ArgusReadConnection() read 16 bytes
> ra[17146]: 04-08-08 15:21:31.6977 ArgusReadConnection() ARGUS_START Mar.
> ra[17146]: 04-08-08 15:21:31.6978 ArgusReadConnection() read failed for
> ARGUS_START Mar Success.
> ra[17146]: 04-08-08 15:21:31.6980 ArgusReadStream() ArgusRemoteFDs is empty
> ra[17146]: 04-08-08 15:21:31.6980 ArgusShutDown (0)
> 
> On Gateway:
> /usr/local/sbin/argus -D2 -F /usr/local/etc/argus.conf -P 561 -B 172.24.4.1
>   (anything above debug level 2 segfaults - why?)
> ...
> argus[37809]: 08 Aug 04 15:21:31 ArgusNewSocket (10) returning 0x8177000
> argus[37809]: 08 Aug 04 15:21:31 ArgusNewSocket (9) returning 0x8188000
> argus[37809]: 08 Aug 04 15:21:31 ArgusAuthenticateClient() returning 128
> argus[37809]: 08 Aug 04 15:21:31 ArgusInitClientProcess(0x813601c,
> (null)) returning
> argus[37809]: client done.
> argus[37809]: 08 Aug 04 15:21:31 ArgusShutDown(ArgusError)
> ...
> 
>     Now, that "ArgusReadConnection() read failed for ARGUS_START Mar
> Success." on the client seems like a pretty peculiar sort of error (Mar?
> Success!?!? - looking at argus_parse.c, how could (cnt = read (fd,
> &argus.argus_mar, size)) != size, unless sizeof() or an argus typedef
> are hosed?),


Hmmm...Be aware that read() returns an ssize_t value.
Make sure that its return value is compared with other ssize_t values.
Ditto for write().

    See net-snmp bug# 936483
 >    http://sourceforge.net/tracker/?group_id=12694
 >    &atid=112694&func=detail&aid=936483

I see that the value returned from read() is mostly compared with
an off_t type of object, when it is not assigned to an int object.

I don't know if off_t is the same size as ssize_t everywhere;
I can imagine it is not the same as "int", in some places.

Suggest changing the declaration of "cnt" or "retn" to ssize_t,
and comparing result with an ssize_t test value.


All the Best,
-Mike Slifcak


  but it's not giving me any clues beyond what I was gleaning
> from the "No data seen" output. Alas, I am a bear of little brain.
> 
>     OTOH, the "ArgusAuthenticateClient() returning 128" on the server
> seems very suggestive, except, when I nc from the Monitoring Station to
> port 561 on the Gateway, I see the same behavior on server, which
> continues to spew data back at nc. Looking at ArgusAuth.c, I don't
> understand where retn could be set to 128 as I don't have sasl on the
> Gateway, and this behavior is invariant whether or not I pass configure
> --with-sasl=no.
> 
>     Could it be that the server is sending a spurious authetication
> failure message to the client which it isn't expecting, which kills it.
> Or is the answer in the client's "ArgusReadStream() ArgusRemoteFDs is
> empty", which lies beyond my patience/skill to unravel?
> 
>     Further help would be much appreciated.
> 
>     Joe
> 
>