I think we may be onto something. The cf-serverd on the policy host seems to
have ran through the night no problem. I wouldn't call it fixed yet, but it is
encouraging. I'll let it run a couple more days and see if that does it.
Does moving the ThreadUnlock make any sense or am I way off track?
On Dec 11, 2009, at 8:03 AM, Matt Richards wrote:
> Well, it is still doing it. I think it is the cf-server actually causing the
> illegal cipher length in the client. I am using openSSL 0.9.8l. I don't have
> the client side dialog, as it is very random on which host does it (and
> when). I do have the server debug session from the core dump. Ooops, I don't.
> I just modified the server code, now the core is not valid anymore (more on
> that below).
>
> I did see something interesting in SSL though. I wish I had the traceback to
> show, but it was a value passed to from one function to another. Somehow the
> value changed, although I can't see how that can be possible. As a desperate
> stab, I kept the thread locked in server.c (as it is coring in the
> RSA_public_encrypt). I have no idea if it is valid or not (I am weak on
> thread programming), but I'll let it run, see what happens.
>
>
> ThreadLock(cft_system);
>
> if ((out = malloc(encrypted_len+1)) == NULL)
> {
> FatalError("memory failure");
> }
>
> /* ThreadUnlock(cft_system);*/ << moved to after the RSA_public_encrypt
>
> if (RSA_public_encrypt(nonce_len,in,out,newkey,RSA_PKCS1_PADDING) <= 0)
> {
> err = ERR_get_error();
> CfOut(cf_error,"","Public encryption failed =
> %s\n",ERR_reason_error_string(err));
> RSA_free(newkey);
> free(out);
> return false;
> }
>
> ThreadUnlock(cft_system); << moved it here
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
