Hi all,
My application is an ldap client based on openLdap suite. I'm having problems when receiving search responses with incorrect msgId. The problem is: always returns error -1 being impossible to discriminate other situations like remote server close. The application always detach the connection fd when -1 is received (99% is broken connection). But we don't want to do close this when "receive a search response with out-of-context msgId" (usually "out-of-time search result entries" after sending AbandonRequest from client).
I can't use ldap_msgid, because 'LDAPMessage*' is NULL and causes abort() (anyway, no special result code is specified for this situation at ldap_msgid API description).
My code: LDAP* handle = (LDAP*) a_ldap; LDAPMessage* hmessage (NULL); resultCode = ldap_result (handle, LDAP_RES_ANY, LDAP_MSG_ONE, NULL, &hmessage);
// I test the following, hoping result is not -1 with LDAP_RES_UNSOLICITED, but it returned -1 again... if (resultCode.getValue () == -1) resultCode = ldap_result (handle, LDAP_RES_UNSOLICITED, LDAP_MSG_ONE, NULL, &hmessage);
?do you know any other way to identify responses with incorrect msgid?
thnks Regard, Edu
Hi,
When we use: resultCode = ldap_result (handle, LDAP_RES_ANY, LDAP_MSG_ONE, -->NULL<--, &hmessage);
I would like to clarify that -1 value was returned due to a signal on our process which interrupt the ldap_int_select within the ldap_result (where penultimate parameter (timeout) was NULL).
We removed that signal and test again 'ldap_result' with zeroed-timeout (0 secs and 0 usecs):
resultCode = ldap_result (handle, LDAP_RES_ANY, LDAP_MSG_ONE, &zeroed_tv, &hmessage);
(even we have test 50 milisecs)
Now, received response with out-of-context msgId, abort the application (due to assert over NULL hmessage when openLdap invokes 'ldap_msgid()'). We test this, changing msgId on response with TCP Test Tool, but actually, this could happen, as i said at former post, when expired context send AbandonRequest and then the ldap server sends the search result entry out of time. (The caller can expect that the result of an abandoned operation will not be returned from a future call to ldap_result()).
Solutions?
---- 1 - Our ldap server, don't support LDAP_OPT_TIMELIMIT (it is optional), and then could answer out of time after an AbandonRequest received from client (or not) (RFC-compliant).
---- 2 - If we use 'LDAP_RES_ANY' we reach abort() when receive INcorrect message responses. If we use 'LDAP_RES_UNSOLICITED' we reach abort() when receive correct message responses. We can't combine these extract methods: not possible to mask values with OR, they are defined in this way:
#define LDAP_RES_ANY (-1) #define LDAP_RES_UNSOLICITED (0)
Perhaps it's possible to add a new #define like 'LDAP_RES_ALL=-2' which causes different special value returns on ldap_result() to make a distinction about which kind of message we receive: solicited or unsolicited. Or perhaps it's possible to get a not NULL hmessage on last ldap_result parameter, when something incorrect is received (only would be NULL on break connection event).
We reach openldap debug output like this: ../../../libraries/liblber/io.c:516: ber_get_next: Assertion `ber->ber_buf == ((void *)0)' failed.
---- 3 - Avoid sending AbandonRequest in order to keep all (good/bad) contexts, perhaps solve the problem (we suppose ldap_abandon() clears internal openLdap memory resource (*)). We could send the AbandonRequest sometime later (configurable delay), or never send including any "garbage collector" mechanism (not sure if exist any openLdap primitive to do this without ldap_abandon()). We don't like any idea like this. What do you think?
(*) anyone could confirm this ?
---- 4 - We are testing the following code now, but think it couldn't be such complex to afford the problem: (the application is single thread and must keep connection all the time even if incorrect msgId is received)
ualarm (100000, 0); resultCode = ldap_result (handle, LDAP_RES_ANY, LDAP_MSG_ONE, NULL, &hmessage);
// If we receive an unexpected message, ldap_result gets blocked on ldap_int_select due to the extract // method (LDAP_RES_ANY), and the penultimate parameter (NULL is infinite timeout). But this situation // is interrupted with former 'ualarm' signal (100 ms delay)
int xerrno = errno; ualarm (0, 0);
if (resultCode == -1) { int result = -1; bool disconnect (false);
if (ldap_get_option (handle, LDAP_OPT_RESULT_CODE, &result) != LDAP_OPT_SUCCESS) disconnect = true; else if (result == LDAP_SERVER_DOWN) disconnect = true; else if (result == LDAP_CONNECT_ERROR) disconnect = true;
if (disconnect == true && xerrno == EINTR) disconnect = false; }
Indeed, we don't like this method, because we are not sure if fd stream is corrupted after an unexpected message, and probably could affect the next normal ones. We think it must be any simple way to manage this.
We can't found a good point to manage the problem. any idea?
Thanks Eduardo
Regards Edu