Lars Hesel Christensen XX (AH/LMD) wrote:
Ok, what really confused me when looking at this is the fact that the comments for ldap_result (as well as the man pages) claims that we will receive unsolicited messages when calling ldap_result with LDAP_RES_ANY or LDAP_RES_UNSOLICITED.
I'm not sure about how to handle unsolicited messages other than notice of disconnect, but as it is, when the user can just ignore unsolicited messages, I suppose it would be a good thing if the library itself could deal with them and dispose of them. I think this is what is intended when reading the section about unsolicited messages in the RFC. At least it seems to me that it would be bad/confusing if some unsolicited messages are handled by the application and some are handled by the library.
I think it would not be to hard to create a mock-up server that can accept a new session and then send a notice of disconnection to the client. That would be a simple way to test that client-side code/handling of notice of disconnection - whatever the outcome of the above discussion might be :)
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.
Cheers, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------