Re: ldap_simple_bind_s failing

[Neha Agarwalla]

Issue found.
The length of buffer supplied to gethostbyname_r API is hard-coded to 1024.
While the expected output on my machine is more than 1024.

The limit should be increased in future release.



Neha Agarwalla wrote:
>
> Hi,
>
> Our client has a failover setup wherein they have multiple ldap servers.
> When they ping to this particular hostname "thcg.net" then it returns the
> IP address of the LDAP server currently being used.
> If we configure the particular IP address as the hostname in our
> application then we are able to connect to ldap successfully. But if we
> configure "thcg.net" as the hostname then we are unable to connect. In
> effect our application is not able use the functionality fail-over. The
> ldap_simple_bind_s() API fails with error code as 91 and the error message
> as "Can't connect to LDAP server'.
>
> Please help.
>
> Neha
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
>
>

--
View this message in context: http://old.nabble.com/ldap_simple_bind_s-failing-tp33298977p33654839.html
Sent from the Mozilla - Directory mailing list archive at Nabble.com.

[Matthew M. DeLoera]

Hello everyone,

I'm using a 32-bit 6.0.6 LDAP C-SDK DLL, that I build with MozillaBuild, and running with my 32-bit Windows service. The system is Win7 64-bit.

Let me say first off that I did not notice any related patches listed on the wiki, applied since 6.0.6.

And also that I'm investigating my application for any inadvertent sharing of the LDAP instance between threads. I generally try to avoid sharing between threads (trying to keep usage as single-threaded as possible, for simplicity).

With that said, and with the possibility of threading issues, I have encountered this call stack on a remote machine:

NSLDAP32V60.dll!msgid_getdata(void * pTableData=0x110f8d88, void * key=0x0450d478, void * * ppData=0x0450d444) Line 1907 + 0x6 bytes C
NSLDAP32V60.dll!htable_get(HashTable_struct * pTable=0x00c1eec8, void * key=0x0450d478, void * * ppData=0x0450d444) Line 1765 + 0x1a bytes C
NSLDAP32V60.dll!memcache_access(ldapmemcache * cache=0x03e50858, int mode=0, void * pData1=0x0450d48c, void * pData2=0x0450d478, void * pData3=0x03fe1268) Line 1436 + 0x14 bytes C
NSLDAP32V60.dll!memcache_add(ldap * ld=0x00c572a8, unsigned long key=331271083, int msgid=170, const char * basedn=0x03fe1268) Line 1033 + 0x1d bytes C
NSLDAP32V60.dll!ldap_memcache_new(ldap * ld=0x00c572a8, int msgid=170, unsigned long key=331271083, const char * basedn=0x03fe1268) Line 752 + 0x15 bytes C
NSLDAP32V60.dll!nsldapi_search(ldap * ld=0x00c572a8, const char * base=0x03fe1268, int scope=2, const char * filter=0x117f46e8, char * * attrs=0x00000000, int attrsonly=0, ldapcontrol * * serverctrls=0x00000000, ldapcontrol * * clientctrls=0x00000000, int timelimit=-1, int sizelimit=100, int * msgidp=0x111c0a58) Line 239 + 0x15 bytes C
NSLDAP32V60.dll!ldap_search_ext(ldap * ld=0x00c572a8, const char * base=0x03fe1268, int scope=2, const char * filter=0x117f46e8, char * * attrs=0x00000000, int attrsonly=0, ldapcontrol * * serverctrls=0x00000000, ldapcontrol * * clientctrls=0x00000000, timeval * timeoutp=0x00000000, int sizelimit=100, int * msgidp=0x111c0a58) Line 150 + 0x3c bytes C

Apologies for wide lines. I guess my question to you is whether this call stack is remotely familiar to anyone (I can always hope!). Otherwise, I was studying usage of LDAP_MUTEX_LOCK(ld,LDAP_MEMCACHE_LOCK) and the corresponding unlock in ldap_memcache_new. Not fully understanding the lock implementation in Windows, is it possible to get all the way down this stack, and simultaneously call ldap_unbind from another thread? And looking at ldap_unbind, seems like once I'm inside ldap_memcache_new, unbind would block for thread safety.

Hoping someone has any kind of suggestion or idea that might help me. Since I can't reproduce the problem on my debug machine, I can at least try to eliminate any threading issues that have creeped in. Otherwise, not sure what else might be impacting me?

Best regards,
- Matthew