Re: (ITS#8048) back-sock/slapo-sock issue

[hyc@symas.com]

michael@stroeder.com wrote:
> Howard Chu wrote:
>> michael@stroeder.com wrote:
>>> michael@stroeder.com wrote:
>>>> Null-bytes really needed?
>>>
>>> Hmm, with null-bytes the wrong result code is returned to the LDAP cli=
> ent.
>>>
>>> Without null-bytes the correct result code is returned to the client b=
> ut slapd
>>> complains about unknown string:
>>>
>>> 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=3Dwuqww,cn=3Dampua,ou=3Dampu=
> a\ninfo:
>>> NOK\n\n'
>>>
>>> results in log message:
>>>
>>> 559174df str2result (msgid: 1
>>> code: 0
>>>
>>> ) unknown
>>> 559174df str2result (
>>> ) unknown
>> =20
>> I would almost suspect you were running on Windows. None of the behavio=
> r
>> you're reporting occurs for me using the searchexample.pl script.
>
> Your script does not return any real 'RESULT..' responses.

Sure it does:

       print "dn: cn=test, dc=example, dc=com\n";
       print "cn: test\n";
       print "objectclass: cnobject\n";
       print "\n";
       print "RESULT\n";
       print "code: 0\n";
       print "info: answered by process $$\n";

And the result at the client:

violino:~/OD/hobj/tests> ../clients/tools/ldapsearch -x -H ldap://:9011 -b 
dc=example,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# test, example.com
dn: cn=test,dc=example,dc=com
cn: test
objectClass: cnobject

# search result
search: 2
result: 0 Success
text:  answered by process 3077

# numResponses: 2
# numEntries: 1

Notice there are no embedded NUL characters. Only newlines.

> I also have less issues when just returning 'CONTINUE\n'.
>
>> Sounds like your problem is a python runtime configuration, not a slapd=
>
>> bug.
>
> Not on Windows and no run-time configuration involved.
>
> Look at the raw string representations I've posted. That string goes dire=
> ctly
> to SocketServer.BaseRequestHandler.request.sendall(response_str).
>
> Can I raise the debug level? Log level trace does not really show the ori=
> ginal
> byte sequence received by the external listener.

Currently there is no debug code for this.

At any rate, the code uses fgets(3) which stops reading at a newline 
character. The fact that your string isn't being parsed correctly implies 
either libc fgets is broken inside your slapd process (pretty unlikely) or 
your socket sender isn't really sending newline characters.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/