Hi all I've been looking at the Notice of disconnection handling in OpenLDAP and there is a thing that is confusing me a bit. in result.c, the function try_read1msg reads data from socket and creates a new message from that. If we receive an unsolicited message, e.g, notice of disconnection, then the msgId will be zero, and we will go through the following code(taken from /* $OpenLDAP: /libraries/libldap/result.c,v 1.144 2006/12/17 21:04:25 ando Exp $ */): /* message id */ if ( ber_get_int( ber, &id ) == LBER_ERROR ) { ber_free( ber, 1 ); ld->ld_errno = LDAP_DECODING_ERROR; return( -1 ); } /* if it's been abandoned, toss it */ if ( ldap_abandoned( ld, id, &idx ) ) { <REMOVED since the msgId is not abandoned> retry_ber: ber_free( ber, 1 ); if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) ) { goto retry; } --> return( LDAP_MSG_X_KEEP_LOOKING ); /* continue looking */ } lr = ldap_find_request_by_msgid( ld, id ); if ( lr == NULL ) { const char *msg = "unknown"; /* the message type */ tag = ber_peek_tag( ber, &len ); switch ( tag ) { case LBER_ERROR: break; default: msg = ldap_int_msgtype2str( tag ); break; } Debug( LDAP_DEBUG_ANY, "no request for response on ld %p msgid %ld message type %s (tossing)\n", (void *)ld, (long)id, msg ); goto retry_ber; } Assuming there is no more data to be read from the socket we will return in the line marked with the arrow '-->' since ldap_find_request_by_msgid() returns NULL. What confuses me is that later on in try_read1msg we get to (after constructing the message: /* is this the one we're looking for? */ if ( msgid == LDAP_RES_ANY || id == msgid ) { if ( all == LDAP_MSG_ONE || ( newmsg->lm_msgtype != LDAP_RES_SEARCH_RESULT && newmsg->lm_msgtype != LDAP_RES_SEARCH_ENTRY && newmsg->lm_msgtype != LDAP_RES_SEARCH_REFERENCE ) ) { *result = newmsg; ld->ld_errno = LDAP_SUCCESS; return( tag ); } else if ( newmsg->lm_msgtype == LDAP_RES_SEARCH_RESULT) { foundit = 1; /* return the chain later */ } } Do we have a test case testing notice of disconnection? I tried to grep the 'tests' directory for 'notice', 'disconnection' and 'unsolicited' but nothing came up. Perhaps I'm misunderstanding something here, so if I am I would very much appreciate a hint.

-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Lars Hesel Christensen XX (AH/LMD) wrote: > Hi all > > I've been looking at the Notice of disconnection handling in OpenLDAP > and there is a thing that is confusing me a bit. > > in result.c, the function try_read1msg reads data from socket and > creates a new message from that. If we receive an unsolicited message, > e.g, notice of disconnection, then the msgId will be zero, and we will > go through the following code(taken from /* $OpenLDAP: > /libraries/libldap/result.c,v 1.144 2006/12/17 21:04:25 ando Exp $ */): > > /* message id */ > if ( ber_get_int( ber, &id ) == LBER_ERROR ) { > ber_free( ber, 1 ); > ld->ld_errno = LDAP_DECODING_ERROR; > return( -1 ); > } > > /* if it's been abandoned, toss it */ > if ( ldap_abandoned( ld, id, &idx ) ) { > > <REMOVED since the msgId is not abandoned> > > retry_ber: > ber_free( ber, 1 ); > if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) > ) { > goto retry; > } > --> return( LDAP_MSG_X_KEEP_LOOKING ); /* continue > looking */ > } > > lr = ldap_find_request_by_msgid( ld, id ); > if ( lr == NULL ) { > const char *msg = "unknown"; > > /* the message type */ > tag = ber_peek_tag( ber, &len ); > switch ( tag ) { > case LBER_ERROR: > break; > > default: > msg = ldap_int_msgtype2str( tag ); > break; > } > > Debug( LDAP_DEBUG_ANY, > "no request for response on ld %p msgid %ld message type %s > (tossing)\n", > (void *)ld, (long)id, msg ); > > goto retry_ber; > } > > Assuming there is no more data to be read from the socket we will > return in the line marked with the arrow '-->' since > ldap_find_request_by_msgid() returns NULL. > > What confuses me is that later on in try_read1msg we get to (after > constructing the message: > > /* is this the one we're looking for? */ > if ( msgid == LDAP_RES_ANY || id == msgid ) { > if ( all == LDAP_MSG_ONE > || ( newmsg->lm_msgtype != > LDAP_RES_SEARCH_RESULT > && newmsg->lm_msgtype != > LDAP_RES_SEARCH_ENTRY > && newmsg->lm_msgtype != > LDAP_RES_SEARCH_REFERENCE ) ) > { > *result = newmsg; > ld->ld_errno = LDAP_SUCCESS; > return( tag ); > > } else if ( newmsg->lm_msgtype == > LDAP_RES_SEARCH_RESULT) { > foundit = 1; /* return the chain later */ > } > } > > Do we have a test case testing notice of disconnection? I tried to > grep the 'tests' directory for 'notice', 'disconnection' and 'unsolicited' > but nothing came up. > > Perhaps I'm misunderstanding something here, so if I am I would very > much appreciate a hint. > Lars, AFAIK there's no handling, in OpenLDAP's code, of "Notice of Disconnect". Your analysis is correct, the message will be ignored since no request can be found for it. Note that there's no means, right now, to test this condition within OpenLDAP since its server side implementation never returns that message. The point, at the client library side, is: how should this be handled? I mean: if the caller requests "msgid == LDAP_RES_ANY", then the message can be returned, and that's it; otherwise, any unsolicited message should not be queued, but either dealt with by the library, if known, or ignored. This because, in principle, multiple unsolicited messages could be returned, and they would share the same msgid (0). In the case of notice of disconnect, the library could determine it should no longer expect any message from the server and, as soon as the client tries to submit a new request, or asks for response to a pending request, it should return something like LDAP_UNAVAILABLE or a (yet to be defined) specific return code. I think we should discuss details of how this is supposed to be handled by the client library, since RFC 4511 seems to give implementors a lot of freedom. p.

Ah, actually I think you can use the retcode overlay to produce a disconnect result.

Pierangelo Masarati wrote: > Howard Chu wrote: >> Ah, actually I think you can use the retcode overlay to produce a >> disconnect result. > Not sure: the notice of disconnect is a specific response message > which has 0 msgid, while slapo-retcode can return arbitrary response > codes within a response message that's generated in response to a > specific request, using the frontend's response calls, and thus with > the request's msgid. I don't think there's any chance to cleanly > return a response with a msgid of 0, unless the frontend's code is > hacked. OK, never mind. I was thinking that if you configured the overlay to return a SLAPD_DISCONNECT code it would send a response to the actual request and then the frontend would send a separate Disconnect message. However, this will fail with an assert() because you can't send SLAPD_DISCONNECT thru send_ldap_result().

-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] > Lars, right now HEAD code should allow you to experiment with (almost arbitrary) unsolicited responses. The client library right now returns correct unsolicited messages (i.e. extended response messages with msgid == 0) if requested (i.e. if the msgid parameter to ldap_result(3) is either set to LDAP_RES_ANY or LDAP_RES_UNSOLICITED); otherwise, it directly handles the RFC 4511 "Notice of Disconnection" message.

The server allows you to craft a special overlay (slapo-retcode(5)) which can: - return regular response messagess with msgid == 0 - return extended response messages with a given OID and optionally some extended response data - disconnect abruptly without notice. I haven't tested it with in-directory data yet, although the code should be present. I've only tested it with retcode-item configuration directives like retcode-item "cn=unsolicited" 0x00 unsolicited="0" retcode-item "cn=unsolicited-extended" 0x00 unsolicited="1.3.6.1.4.1.1466.20036" retcode-item "cn=disconnect" 0x00 flags=disconnect See test038 for an example that sets up the slapo-retcode(5) overlay. To trigger the abnormal behavior, you can search the database using the "offending" entry as search base, although any operation affecting that DN should be fine.