Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP not working with libcurl multi_socket interface #13998

Closed
saurabhsingh-dev opened this issue Jun 24, 2024 · 3 comments
Closed

LDAP not working with libcurl multi_socket interface #13998

saurabhsingh-dev opened this issue Jun 24, 2024 · 3 comments

Comments

@saurabhsingh-dev
Copy link

saurabhsingh-dev commented Jun 24, 2024

I did this

In my Ldap multi interface program, Ldap request started failing once i upgraded from curl-7.69.0 to curl-8.4.0.

So i tried latest curl version 8.8.0, where still seeing the same issue.

To rule out my program specific issues, i used standalone program for same from curl examples here multi-uv

compiled:
gcc -g -o multi-uv multi-uv.c -luv -lcurl

Run with licurl complied with debug mode:

root@100-65-8-98:/tmp# ./multi-uv ldap://100.66.51.22:10389/ou=consumers,ou=system
./multi-uv: /opt/avi/lib/libcurl.so.4: no version information available (required by ./multi-uv)
CURL_OPENLDAP_TRACE = 65535
curl version: 8.8.0 OpenSSL/1.1.1f
* !!! WARNING !!!
* This is a debug build of libcurl, do not use in production.
Added download ldap://100.66.51.22:10389/ou=consumers,ou=system -> 1.download
* STATE: INIT => SETUP handle 0x55c66c5999f8; line 1971
* STATE: SETUP => CONNECT handle 0x55c66c5999f8; line 1987
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => CONNECTING handle 0x55c66c5999f8; line 2023
*   Trying 100.66.51.22:10389...
* Connected to 100.66.51.22 (100.66.51.22) port 10389
* STATE: CONNECTING => PROTOCONNECT handle 0x55c66c5999f8; line 2131
* LDAP 0x55c66c594bf8 state change from STOP to BIND
* STATE: PROTOCONNECT => PROTOCONNECTING handle 0x55c66c5999f8; line 2155
* Operation timed out after 10008 milliseconds with 0 bytes received
* multi_done[PROTOCONNECTING]: status: 28 prem: 1 done: 0
* multi_done, not reusing connection=0, forbid=0, close=1, premature=1, conn_multiplex=0
* The cache now contains 0 members
* Curl_disconnect(conn #0, dead=1)
* Closing connection
ldap://100.66.51.22:10389/ou=consumers,ou=system DONE

Things i added in mentioned standalone program for testing:

curl_easy_setopt(handle, CURLOPT_VERBOSE, 1L); // debug enable
curl_easy_setopt(handle, CURLOPT_TIMEOUT, 10L); // 2 sec
//added before curl_multi_add_handle

g_version = curl_version_info(CURLVERSION_NOW);
fprintf(stderr, "curl version: %s %s\n", g_version->version, g_version->ssl_version);
// added in main and printed

Points from my debugging using gdb:

  1. oldap_connecting is been called immediately after oldap_connect, since response is not received yet, ldap_result returns 0, which is timeout.
  2. multi_runsingle is not calling oldap_connecting again for response check.
  3. looks multi_runsingle -> oldp_connecting should be called when data is available or repeated calls should be made.

I expected the following

Following run with curl 7.69.0, works fine.

root@100-65-8-98:/tmp# ./multi-uv ldap://100.66.51.22:10389/ou=consumers,ou=system
./multi-uv: /opt/avi/lib/libcurl.so.4: no version information available (required by ./multi-uv)
CURL_OPENLDAP_TRACE = 65535
curl version: 7.69.0 OpenSSL/1.1.1f
Added download ldap://100.66.51.22:10389/ou=consumers,ou=system -> 1.download
* STATE: INIT => CONNECT handle 0x564c5f4ca888; line 1617 (connection #-5000)
* Marked for [keep alive]: OpenLDAP default
* Added connection 0. The cache now contains 1 members
*   Trying 100.66.51.22:10389...
* STATE: CONNECT => WAITCONNECT handle 0x564c5f4ca888; line 1673 (connection #0)
* Connected to 100.66.51.22 (100.66.51.22) port 10389 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x564c5f4ca888; line 1791 (connection #0)
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x564c5f4ca888; line 1808 (connection #0)
* STATE: PROTOCONNECT => DO handle 0x564c5f4ca888; line 1827 (connection #0)
* LDAP local: ldap://100.66.51.22:10389/ou=consumers,ou=system
* STATE: DO => DO_DONE handle 0x564c5f4ca888; line 1882 (connection #0)
* STATE: DO_DONE => PERFORM handle 0x564c5f4ca888; line 2003 (connection #0)
* STATE: PERFORM => DONE handle 0x564c5f4ca888; line 2193 (connection #0)
* multi_done
* Connection #0 to host 100.66.51.22 left intact
* Expire cleared (transfer 0x564c5f4ca888)
ldap://100.66.51.22:10389/ou=consumers,ou=system DONE

curl/libcurl version

root@100-65-8-98:/opt/avi/lib# curl -V
WARNING: this libcurl is Debug-enabled, do not use in production

curl 8.8.0 (x86_64-pc-linux-gnu) libcurl/8.8.0 OpenSSL/1.1.1f zlib/1.2.11 libidn2/2.2.0 nghttp2/1.40.0 OpenLDAP/2.4.49
Release-Date: 2024-05-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS Debug HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP TrackMemory UnixSockets

operating system

Linux 100-65-8-98 5.4.0-174-generic #193-Ubuntu SMP Thu Mar 7 14:29:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

@saurabhsingh-dev saurabhsingh-dev changed the title Ldap not working with licurl multi interface. Ldap not working with libcurl multi interface. Jun 24, 2024
@bagder bagder added the LDAP label Jun 24, 2024
@bagder bagder changed the title Ldap not working with libcurl multi interface. LDAP not working with libcurl multi_socket interface Jun 24, 2024
@bagder
Copy link
Member

bagder commented Jun 25, 2024

I believe this problem can be reproduced with a debug-build on git master like this:

curl --test-event -v "ldaps://ldap.udel.edu/ou=people,o=udel.edu??sub?(udUsernum=82515)"

icing added a commit to icing/curl that referenced this issue Jun 25, 2024
- in phase CONNECTING/TUNNELING/PROTOCONNECT, retrieve
  the socket from the connection filters and do not rely
  on `conn->sockfd` being already set by the transfer.
- this applies to the default behaviour, a protocol handler
  may override this via its callbacks.
- fixes timeout in curl#13998
icing added a commit to icing/curl that referenced this issue Jun 25, 2024
    - in phase CONNECTING/TUNNELING/PROTOCONNECT, retrieve
      the socket from the connection filters and do not rely
      on `conn->sockfd` being already set by the transfer.
    - this applies to the default behaviour, a protocol handler
      may override this via its callbacks.
    - add a warning message in multi_getsock() when the transfer
      is expected to have something in its pollset, but instead
      it is empty.
    - fixes timeout in curl#13998
@icing
Copy link
Contributor

icing commented Jun 25, 2024

Fixed for me in #14011.

@bagder bagder closed this as completed in def99d8 Jun 25, 2024
@saurabhsingh-dev
Copy link
Author

saurabhsingh-dev commented Jun 26, 2024

Thanks for quick resolution. Verified the fix in my environment. its working for me now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants