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.