RC3 1.5 LDAP ldap_simple_bind: Can't contact LDAP server

[bogus]

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.

 

[mistwang]

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

 

[bogus]

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?

 

[mistwang]

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?

 

[mistwang]

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.

 

[bogus]

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

 

[mistwang]

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. ;-)

 

[bogus]

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.

 

[mistwang]

* lsws: R 4025478480:4025478480(0) win 0 (DF)

This means the server side closed the connection.

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.

 

[bogus]

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

 

[mistwang]

The "R" packet is originated by the client, but I thought it is from the server side.

So, it is definitely a problem of the client.
The differences between the LDAP APIs called by "ldapsearch" and "lsws" are: "ldapsearch" use synchronized API, lsws use asynchonized API in order not to let LDAP activities block the whole server process.

After digging into OpenLDAP's source code, we found that some of their asynchronized API is not really asynchronized, like "ldap_simple_bind" stays synchronized. there is no real difference between "ldap_simple_bind_s" and "ldap_simple_bind".

We switch to synchronized API when we need to connect to LDAP server in 1.5RC4 release. Fortunately, we only need to do it once per LDAP server, and the established connection can be reused for multiple LDAP queries.

So, in production, it is better to have LDAP server resided on the same server running lsws or at least to have two servers connected by high speed swithed LAN.

Please try just released 1.5RC4, hope it works.

 

[bogus]

I've upgraded to RC4 and... :cry:

Exactly the same scenario (client resets connection):


12:19:52.356385 81.56.193.144.49672 > 80.170.141.234.ldap: S 1726673214:1726673214(0) win 5808 <mss 1452,sackOK,timestamp 129583925 0,nop,wscale 0> (DF)
0x0000 4500 003c ba0b 4000 4006 8f53 5138 c190 E..<..@.@..SQ8..
0x0010 50aa 8dea c208 0185 66ea f13e 0000 0000 P.......f..>....
0x0020 a002 16b0 d15c 0000 0204 05ac 0402 080a .....\..........
0x0030 07b9 4b35 0000 0000 0103 0300 ..K5........
12:19:52.499361 80.170.141.234.ldap > 81.56.193.144.49672: S 1957328433:1957328433(0) ack 1726673215 win 5632 <mss 1412,sackOK,timestamp 318381160 129583925,nop,wscale 0> (DF)
0x0000 4500 003c 0000 4000 3c06 4d5f 50aa 8dea E..<..@.<.M_P...
0x0010 5138 c190 0185 c208 74aa 7631 66ea f13f Q8......t.v1f..?
0x0020 a012 1600 b7e5 0000 0204 0584 0402 080a ................
0x0030 12fa 1c68 07b9 4b35 0103 0300 ...h..K5....
12:19:52.499419 81.56.193.144.49672 > 80.170.141.234.ldap: R 1726673215:1726673215(0) win 0 (DF)
0x0000 4500 0028 0000 4000 4006 4973 5138 c190 E..(..@.@.IsQ8..
0x0010 50aa 8dea c208 0185 66ea f13f 0000 0000 P.......f..?....
0x0020 5004 0000 a2cb 0000 P.......


The link is slow (128kbits) between client and server, but other clients don't complain. And it is still fast enough.

In LSWS the error :
ldap_simple_bind_s: Can't contact LDAP server

now appears 4 times on each attempt.

I'm sorry. But is there anybody else out there who tried the LDAP feature over the internet ?

 

[mistwang]

Holy crab! :evil:

I think it has something to do with the slow connection.

We find a way to enable LDAP debug logging. Please download RC4 package again. You can find the log output in lsws/logs/stderr.log, pleae post it here.

Also, please do "ldapsearch -d 255 ..." and post the debug output as well.

Right now, you are the only one testing this feature. Hopefully, Paul, our another beta user, will get his hand on this soon.

Thank you very much for your help!