[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
- To: Howard Chu <hyc@symas.com>
- Subject: Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
- From: openldap-technical@kolttonen.fi
- Date: Thu, 24 Jan 2019 19:57:03 +0200 (EET)
- Cc: openldap-technical@openldap.org
- Dkim-filter: OpenDKIM Filter v2.11.0 vcust561.louhi.net x0OHuv1F028085
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolttonen.fi; s=mail; t=1548352619; bh=X2lLPKWJZAtfR0DlTseRS4zUSxfdjV3QzUdWSpaJfCw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mC+A1Rm3WSd0vVhPfA5Ca4HrRrP+qJf1znWdZHocB1PGbtByy9WFg7W24xJfe/tx4 e8okjY6iw7Squ7imINzaAk/9XxF9ukwQ6tuV1RWDjw+uErlNr5LRkn6PNks3AR6hcM 6mQBeiA7+2+NKAvcm/BTK2zlUtIXEW4+GVYJ9cBZfOWWcmNU+hgUE3asEWyw0WG5Dv BV2+WzOLDpGPgJ0v5es1Ioc4QO+ThX80ChSD0CG1v/Dy30T9vExolS5H/ll0ft3+Lk 3wMBPDBTd7iyYFj+/eK+RJFeFCKFhMho5uPBhTDVLKnMseo/aDIepzdW/uZJPheOTd +3CLXhtSt/Oug==
- In-reply-to: <alpine.LFD.2.21.1901221628480.17381@localhost>
- References: <20190117163350.GA26474@helsinki.fi> <45403ce3-d89f-d8d3-7190-817198830d7c@symas.com> <alpine.LFD.2.21.1901221628480.17381@localhost>
- User-agent: Alpine 2.21 (LFD 202 2017-01-01)
Hello again,
On Tue, 22 Jan 2019, openldap-technical@kolttonen.fi wrote:
> By the way, I am wondering here about the correctness of parameter
>
> li->li_timeout[ SLAP_OP_EXTENDED ]
>
> slap.h has:
>
> /*
> * Operation indices
> */
> typedef enum {
> SLAP_OP_BIND = 0,
> SLAP_OP_UNBIND,
> SLAP_OP_SEARCH,
> SLAP_OP_COMPARE,
> SLAP_OP_MODIFY,
> SLAP_OP_MODRDN,
> SLAP_OP_ADD,
> SLAP_OP_DELETE,
> SLAP_OP_ABANDON,
> SLAP_OP_EXTENDED,
> SLAP_OP_LAST
> } slap_op_t;
>
> So SLAP_OP_EXTENDED has value 9. But back-ldap/config.c has:
>
> /* see enum in slap.h */
> static slap_cf_aux_table timeout_table[] = {
> { BER_BVC("bind="), SLAP_OP_BIND * sizeof( time_t ), 'u', 0, NULL },
> /* unbind makes no sense */
> { BER_BVC("add="), SLAP_OP_ADD * sizeof( time_t ), 'u', 0, NULL },
> { BER_BVC("delete="), SLAP_OP_DELETE * sizeof( time_t ), 'u', 0, NULL },
> { BER_BVC("modrdn="), SLAP_OP_MODRDN * sizeof( time_t ), 'u', 0, NULL },
> { BER_BVC("modify="), SLAP_OP_MODIFY * sizeof( time_t ), 'u', 0, NULL },
> { BER_BVC("compare="), SLAP_OP_COMPARE * sizeof( time_t ), 'u', 0, NULL },
> { BER_BVC("search="), SLAP_OP_SEARCH * sizeof( time_t ), 'u', 0, NULL },
> /* abandon makes little sense */
> #if 0 /* not implemented yet */
> { BER_BVC("extended="), SLAP_OP_EXTENDED * sizeof( time_t ), 'u', 0, NULL },
> #endif
> { BER_BVNULL, 0, 0, 0, NULL }
> };
>
> Hmmm, SLAP_OP_EXTENDED is not defined, so does li->li_timeout[ SLAP_OP_EXTENDED ]
> end up pointing outside of this timeout_table[]? I am not sure.
No, it does not point there. I read some more code and "li" is of type
struct ldapinfo_t that has member:
time_t li_timeout[ SLAP_OP_LAST ];
And hence we have an array:
li_timeout[ 10 ]
so pointing to li_timeout[ SLAP_OP_EXTENDED ] points to li_timeout[ 9 ]
and there is nothing wrong with that.
I do not know if I understand the code here, but I suppose this
li_timeout[ SLAP_OP_EXTENDED ] has value 0. That is why the else-branch is
taken, giving the default 0.1 second timeout for TLS initialization. Is
this correct, and perhaps safe to increase the value here?
Best regards,
Unto Sten