Hi Daniel,

I've been playing with this also and have narrowed it down to the following lines (39-40)
in    src/external/zlib-1.2.3/compress.c:

    stream.avail_out = (uInt)*destLen;
    if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;


If you change line 40 to:

    if ((uInt)stream.avail_out != (uInt)*destLen) return Z_BUF_ERROR;

it seems to fix this problem, but I have a feeling it defeats the original intent (though I'm not sure what the original intent was).

Martin

Daniel Cid wrote:

It looks like there is a problem with zlib and 64 bits (since the errors
are during the compression phase). I am doing some testings in here,
but unfortunately I don't have any 64b machine to test..

*btw, thanks everyone for the useful information you are sending me...

*Looking at zlib page, they don't mention any problem with 64 bits,
so it could still be something in ossec...

I will post something regarding that soon.

--
Daniel B. Cid
dcid ( at ) ossec.net


On 8/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


David Vasil wrote:
> Martin Gottlieb wrote:
> >
> > Was a solution ever posted for this one ?  I checked the archives and
> > did not see one.
> >
> > I am experiencing the same problem on 2 different x86_64 boxes set up as
> > agents.  I'm getting "Error compressing string"
> > followed by "Error creating encrypted message" errors.  I did compile
> > ossec locally on each machine.
>
> Nope, no solution yet.  I have tried compiling from source as well and
> it gave the same problems as with the RPM package I created.
>
> --
> -dave

I had an x86_64 build acting as a server and a i386 build acting as a
client, and got 'error uncompressing string'. By replacing the x86_64
server with the i386 server, the error is gone and events are being
logged. It appears to me that at least some part of ossec is not 64-bit
clean.


Reply via email to