|
RC3 1.5 LDAP ldap_simple_bind: Can't contact LDAP server
I can't undestand this error:
[my.host.name] ldap_simple_bind: Can't contact LDAP server The LDAP is fully reachable, and I do browse the directory with any other clent. My ldap url is all right, and the hostname resolvable. I get the same error when I enter the IP adress, anyway. And even at full debug level, I can't have more info. What/where should I investigate ? Thank you. |
It is strange.
Which Linux distribution are you using? What kind of LDAP server is it? OpenLDAP or a commercial one? Is that a TLS or plain connection? LSWS use OpenLDAP's client library to contact LDAP server, and that's the error message reported by the library. If you have not done so, you can try to do a search with OpenLDAP's command line client "ldapsearch" with the same information in your LDAP url, see if it works. Also you can use command "tcpdump my.host.name" to trace tcp activities between two machines, please let me know what you get. Best Regards, George |
I'm running OpenLDAP 2.1.22 on a Mandrake 9.2 on both the server and client.
ldapsearch does work and contact the server. tcpdump shows one packet exchange only between LSWS and Directory. Did you program some timeout? |
No, lsws does not explicitly set a timeout, the default should be used.
Does the LDAP server require authentication? Is SASL authentication being used? lsws only do simple authentication though. Is TLS connection being used? |
lsws is linked with OpenLDAP 2.2.11 client library, so it may not compatible with 2.1.x releases. Can you try 2.2.x.
Or, if you think 2.1.x release is more stable, we can switch to 2.1 then. |
We use simple authentication, no TLS.
Version 2.1.22 of OpenLdap is not a choice, it is the default bundlede with Mandrake 9.2. That should not prevent connexion, as the LDAP protocol standard is not concerned by OpenLDAP versions. The most frustrating is that OpenLdap server does not mention anything in its logs... :evil: :x |
We had installed Mandrake 9.2 on one of our test machine.
We run lsws on that machine, connected to ldap server on a Redhat box successfully. Then we installed the default openload packages on Mandrake 9.2 CD, setup our test user DB, and successfully connected to the Mandrake box from the redhat machine. So, the problem should be your test environment, please check IPTable configuration, ACL configure in slapd configuration, etc. Maybe you should take a closer look at the content of package captured by tcpdump, compare it to data captured while running "ldapsearch". You can try "strace" to debug the problem as well. We do downgrade the linked client library to 2.1.30 (the latest stable release), but as you said, it should not matter and we expect the same result with 2.2.x library. We will release RC4 with some minor bug fixes soon, hope the strange problem disappear. ;-) |
tcpdump comparison between ldapsearch (which works) and lsws.
The first request and response packets between client and server are the roughly the same in both cases. But then, the following packets, emitted by the client differ : * ldapsearch: . ack 1 win 5808 <nop,nop,timestamp 113127116 301924678> (DF) and a successful dialogue takes place... * lsws: R 4025478480:4025478480(0) win 0 (DF) and then nothing more. I'm unable to interpret that. Any hints ? Thank you. |
Quote:
What packets is exchanged before this one? "S" (SYN) packet or "P" (data) packet? "-x" switch (simple bind method) should be used with "ldapsearch" command in order to match lsws'. Please add "-X" parameter to "tcpdump" command to view the complete packet data. Make sure lsws and ldapsearch connect to the same port on the server. If you don't mind, you can pm or email me output of tcpdump along with the ldapsearch command and the LDAP URL, I am more than happy to help analysing the problem. Also, you can try lsws and ldap server on the same machine, network connection should not be an issue then. |
Here are the complete tcpdump -X.
ldapsearch to server (successful -- and yes I use -x ) : 14:01:54.819321 81.56.193.144.49217 > 80.170.141.234.ldap: S 834992559:834992559(0) win 5808 <mss 1452,sackOK,timestamp 121556171 0,nop,wscale 0> (DF) 0x0000 4500 003c 3564 4000 4006 13fb 5138 c190 E..<5d@.@...Q8.. 0x0010 50aa 8dea c041 0185 31c4 f9af 0000 0000 P....A..1....... 0x0020 a002 16b0 7ebd 0000 0204 05ac 0402 080a ....~........... 0x0030 073e cccb 0000 0000 0103 0300 .>.......... 14:01:55.138146 80.170.141.234.ldap > 81.56.193.144.49217: S 2577382112:2577382112(0) ack 834992560 win 5632 <mss 1412,sackOK,timestamp 310353647 121556171,nop,wscale 0> (DF) 0x0000 4500 003c 0000 4000 3c06 4d5f 50aa 8dea E..<..@.<.M_P... 0x0010 5138 c190 0185 c041 999f bae0 31c4 f9b0 Q8.....A....1... 0x0020 a012 1600 7995 0000 0204 0584 0402 080a ....y........... 0x0030 127f 9eef 073e cccb 0103 0300 .....>...... 14:01:55.138211 81.56.193.144.49217 > 80.170.141.234.ldap: . ack 1 win 5808 <nop,nop,timestamp 121556203 310353647> (DF) 0x0000 4500 0034 3565 4000 4006 1402 5138 c190 E..45e@.@...Q8.. 0x0010 50aa 8dea c041 0185 31c4 f9b0 999f bae1 P....A..1....... 0x0020 8010 16b0 a75a 0000 0101 080a 073e cceb .....Z.......>.. 0x0030 127f 9eef And it continues successfully. LSWS to server (fails) : 14:05:16.382236 81.56.193.144.49224 > 80.170.141.234.ldap: S 1049213351:1049213351(0) win 5808 <mss 1452,sackOK,timestamp 121576327 0,nop,wscale 0> (DF) 0x0000 4500 003c a220 4000 4006 a73e 5138 c190 E..<..@.@..>Q8.. 0x0010 50aa 8dea c048 0185 3e89 b9a7 0000 0000 P....H..>....... 0x0020 a002 16b0 633d 0000 0204 05ac 0402 080a ....c=.......... 0x0030 073f 1b87 0000 0000 0103 0300 .?.......... 14:05:16.621406 80.170.141.234.ldap > 81.56.193.144.49224: S 2777118689:2777118689(0) ack 1049213352 win 5632 <mss 1412,sackOK,timestamp 310373802 121576327,nop,wscale 0> (DF) 0x0000 4500 003c 0000 4000 3c06 4d5f 50aa 8dea E..<..@.<.M_P... 0x0010 5138 c190 0185 c048 a587 77e1 3e89 b9a8 Q8.....H..w.>... 0x0020 a012 1600 4671 0000 0204 0584 0402 080a ....Fq.......... 0x0030 127f edaa 073f 1b87 0103 0300 .....?...... 14:05:16.621456 81.56.193.144.49224 > 80.170.141.234.ldap: R 1049213352:1049213352(0) win 0 (DF) 0x0000 4500 0028 0000 4000 4006 4973 5138 c190 E..(..@.@.IsQ8.. 0x0010 50aa 8dea c048 0185 3e89 b9a8 0000 0000 P....H..>....... 0x0020 5004 0000 0484 0000 P....... And nothing more. What do you see ? Undestanding those traces is for me like reading the future in the coffee. :wink: Sincerely |
| All times are GMT -7. The time now is 01:59 PM. |