- openldap-bugs - openldap.org

Re: (ITS#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

Maykel Moya wrote: > El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > >> moya(a)latertulia.org wrote: >>> Full_Name: Maykel Moya >>> Version: 2.4.11 >>> OS: Debian Lenny >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.55.135.211) >>> >>> >>> It's second time that I have bitten by this: >>> >>> Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. >>> >>> After that I'm unable to bind against the DSA. The problem has arise in two >>> independent systems. >> This is now fixed in HEAD. > > Oh, thanks. Is there a way I can get the patch for applying it to my > system? See the diff here http://www.openldap.org/lists/openldap-commit/200811/msg00034.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5794) Password exop unwilling to verify old password
by hyc＠symas.com 06 Nov '08

06 Nov '08

aja(a)nlgroup.ca wrote: > Full_Name: Arthur Anhalt > Version: 2.4.12 > OS: Ubuntu 8.04 > URL: > Submission from: (NULL) (205.200.169.138) > > > When parsing password change extended operations, > servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with > LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0. > > In libraries/liblutil/passwd.c:chk_crypt will return an error is the old and > new > passwords do not end with a null terminator. I believe more of the chk_* > functions > return the same error. > > This is the same bug as ITS#5575, but affects the core system, not contributed > code. Fixed in HEAD, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5783) Possible DB corruption
by moya＠latertulia.org 06 Nov '08

06 Nov '08

El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > moya(a)latertulia.org wrote: > > Full_Name: Maykel Moya > > Version: 2.4.11 > > OS: Debian Lenny > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (200.55.135.211) > > > > > > It's second time that I have bitten by this: > > > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > > > After that I'm unable to bind against the DSA. The problem has arise in two > > independent systems. > > This is now fixed in HEAD. Oh, thanks. Is there a way I can get the patch for applying it to my system? Regards, maykel

1 0

Re: (ITS#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

moya(a)latertulia.org wrote: > Full_Name: Maykel Moya > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.55.135.211) > > > It's second time that I have bitten by this: > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > After that I'm unable to bind against the DSA. The problem has arise in two > independent systems. This is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com 06 Nov '08

06 Nov '08

hyc(a)symas.com wrote: > emmanuel.duru(a)atosorigin.com wrote: >> Full_Name: Emmanuel Duru >> Version: 2.4.11 >> OS: Windows >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.78.0.137) >> >> >> I have set a rootdn on cn=config which is a real entry >> (cn=admin,ou=somewhere,o=myorg,c=fr). >> I bind with this DN. >> I perform a change on cn=config (change the log level). >> At next slapd startup, I get: >> PROXIED attributeDescription "OU" inserted. >> PROXIED attributeDescription "O" inserted. >> PROXIED attributeDescription "C" inserted. >> and then when trying to bind, I get an invalid credentials error (49). >> The problem seems to come from modifiersname in cn=config entry, because if I >> delete this attribute and restarts slapd, all is fine. > > Ah, thanks for this. You're seeing the same as #5783, but you've provided much > more useful information here. > Now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com 06 Nov '08

06 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I have set a rootdn on cn=config which is a real entry > (cn=admin,ou=somewhere,o=myorg,c=fr). > I bind with this DN. > I perform a change on cn=config (change the log level). > At next slapd startup, I get: > PROXIED attributeDescription "OU" inserted. > PROXIED attributeDescription "O" inserted. > PROXIED attributeDescription "C" inserted. > and then when trying to bind, I get an invalid credentials error (49). > The problem seems to come from modifiersname in cn=config entry, because if I > delete this attribute and restarts slapd, all is fine. Ah, thanks for this. You're seeing the same as #5783, but you've provided much more useful information here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5795) Modification of cn=config prevents to bind at next directory restart
by emmanuel.duru＠atosorigin.com 06 Nov '08

06 Nov '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I have set a rootdn on cn=config which is a real entry (cn=admin,ou=somewhere,o=myorg,c=fr). I bind with this DN. I perform a change on cn=config (change the log level). At next slapd startup, I get: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "O" inserted. PROXIED attributeDescription "C" inserted. and then when trying to bind, I get an invalid credentials error (49). The problem seems to come from modifiersname in cn=config entry, because if I delete this attribute and restarts slapd, all is fine.

1 0

(ITS#5794) Password exop unwilling to verify old password
by aja＠nlgroup.ca 05 Nov '08

05 Nov '08

Full_Name: Arthur Anhalt Version: 2.4.12 OS: Ubuntu 8.04 URL: Submission from: (NULL) (205.200.169.138) When parsing password change extended operations, servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0. In libraries/liblutil/passwd.c:chk_crypt will return an error is the old and new passwords do not end with a null terminator. I believe more of the chk_* functions return the same error. This is the same bug as ITS#5575, but affects the core system, not contributed code.

1 0

(ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 05 Nov '08

05 Nov '08

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Hi all, Just a quick note to say it would be nice to be able to break out loglevel 256 i.e. Log just writes. The same as accesslog config. Thanks, Gavin.

1 0

(ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Current draft-zeilenga-ldap-relax requires the DSA to modify the structuralObjectClass attribute of an entry based on modifications of the structural objectClass of that entry. Slapd doesn't implement this; in order to obtain the desired effect, one needs to explicitly modify the structuralObjectClass attribute accordingly. This is explicitly forbidden by draft-zeilenga-ldap-relax. p.

1 0

Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Maykel Moya wrote: > El mar, 04-11-2008 a las 20:20 +0100, Pierangelo Masarati escribió: > >> This does not look like a db corruption. It looks like you restarted >> slapd with back-config in a compromised state, since it is now missing >> the definition of "dc", which is in core.schema. You don't specify how >> you edited cn=config; did you manually edited the corresponding ldif >> files? You're supposed to modify them only via operations using the >> LDAP protocol while the server is running. > > Well, maybe a better title would be: possible cn=config backend > corruption, to make a diference with classic DB usage to refer to > HDB/BDB backends. > > I added olcTLS* fields via normal ldap operations, not by manually > editing text files inside /etc/ldap/slapd.d. Specifically I used a > frontend called luma, which is built around python-ldap. OK. Is the issue reproducible? Can you provide a simple initial slapd.conf and an LDIF containing the modifications that triggered the issue, along with a clear sequence of steps required to reproduce it? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5783) Possible DB corruption
by moya＠latertulia.org 04 Nov '08

04 Nov '08

El mar, 04-11-2008 a las 20:20 +0100, Pierangelo Masarati escribió: > This does not look like a db corruption. It looks like you restarted > slapd with back-config in a compromised state, since it is now missing > the definition of "dc", which is in core.schema. You don't specify how > you edited cn=config; did you manually edited the corresponding ldif > files? You're supposed to modify them only via operations using the > LDAP protocol while the server is running. Well, maybe a better title would be: possible cn=config backend corruption, to make a diference with classic DB usage to refer to HDB/BDB backends. I added olcTLS* fields via normal ldap operations, not by manually editing text files inside /etc/ldap/slapd.d. Specifically I used a frontend called luma, which is built around python-ldap. Cheers, maykel

1 0

Re: (ITS#5764) addpartial patch
by hyc＠symas.com 04 Nov '08

04 Nov '08

dhawes(a)vt.edu wrote: > The patch referenced previously can be discarded. This patch contains > all changes against 2.4.12. I suspect HEAD and 2.4.12 are identical here so it's no big deal this time, but remember for future reference, http://www.openldap.org/devel/contributing.html all contributions must be relative to HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5764) addpartial patch
by dhawes＠vt.edu 04 Nov '08

04 Nov '08

dhawes(a)vt.edu wrote: > Pierangelo Masarati wrote: >> dhawes(a)vt.edu wrote: >>> Full_Name: David Hawes >>> Version: 2.4.12 >>> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch >>> Submission from: (NULL) (128.173.38.164) >>> >>> >>> This patch includes the following changes: >>> >>> - -fPIC added to the Makefile for compilation on x86_64 systems. >>> - No longer use be_search() to retrieve the entry that is to be >>> compared. Use >>> be_entry_get_rw() instead. >> You should probably use overlay_entry_get_ov() rather than >> be_entry_get_rw() from inside an overlay (AFAIR). > > Okay, I'll make that change, thanks. > > I notice that most overlays seem to use be_entry_get_rw(), and one > (translucent) uses both. What is the reasoning to use one over the other? New patch that uses overlay_entry_get_ov() available at: ftp://ftp.openldap.org/incoming/david-hawes-081104.patch The patch referenced previously can be discarded. This patch contains all changes against 2.4.12.

1 0

Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it 04 Nov '08

04 Nov '08

moya(a)latertulia.org wrote: > Full_Name: Maykel Moya > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.55.135.211) > > > It's second time that I have bitten by this: > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > After that I'm unable to bind against the DSA. The problem has arise in two > independent systems. > > Steps to reproduce: > > 1. Create a minor db (like Debian does), a dc=foo,dc=org node and a > cn=admin,rootdn node > 2. Migrate to cn=config > 3. Edit cn=config > I've added olcTLSCACertificateFile / olcTLSCertificateFile / > olcTLSCertificateKeyFiel attributes > 4. Restart the server > > After restarting I see the PROXIED error. I'd wrote to the list before [1][2] > but the same thing has come in another system. This does not look like a db corruption. It looks like you restarted slapd with back-config in a compromised state, since it is now missing the definition of "dc", which is in core.schema. You don't specify how you edited cn=config; did you manually edited the corresponding ldif files? You're supposed to modify them only via operations using the LDAP protocol while the server is running. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 04 Nov '08

04 Nov '08

Howard Chu wrote : >I see. > >This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >cleanly before, there will be no scan on the next startup. Hi Howard, Thanks for the corrections. We tested the HEAD extracted on monday november 3. Unfortunately the problem explained in point 2 persists (even after a clean shutdown). Our directory contains 10 million entries. It can evolve to 40 million entries next year. The local sacanning speed is around 250 000 entries per minute. So the scan of the recent objects on the standby mirror after startup can take several minutes (unless if we distribute the write operations on both mirrors). Best Regards Ali

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 04 Nov '08

04 Nov '08

We tested the HEAD version extracted november 4th : the problem is fixed. The ITS can be closed. thank you for your help ! Best regards Sylvain Thomas

1 0

Re: (ITS#5789) using IP address in CN with GnuTLS
by hyc＠symas.com 04 Nov '08

04 Nov '08

leva(a)ecentrum.hu wrote: > Full_Name: LÉVAI Dániel > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.131.56.68) > > > I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. > The GnuTLS version is 2.4.2. > > So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? > > And please allow me include some additional information, which was told me by > Philip Guenther on openldap-software@: > "It appears the routine used with GNUtls > refuses to match IP addresses against a CN subjects component, thus > explaining that weird message. > > (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname > doesn't look like an IPv6 or IPv4 address, while the subject CN test needs > 'len1' to be the same as the length of the CN value.)" Thanks for the report, now fixed in HEAD. Note that using an IP address in the CN is not the way you're supposed to generate certs; IP addresses belong in the subjectAltName extension. The CN is only supposed to contain a fully qualified domain name. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5791) searches with entryDN in the filter scan the whole db
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Filtering for entryDN equality requires scanning the whole DB, although dn's are indexed in dn2id. See also ITS#5790

1 0

(ITS#5790) Indexing for entryDN results in no entry found
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando If an explicit equality index is set for entryDN, searches with entryDN in the filter find no entries.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 04 Nov '08

04 Nov '08

On 4 Nov 2008, at 09:26, Pierangelo Masarati wrote: > toby(a)inf.ed.ac.uk wrote: >> Hi there, is there any further debugging I could usefully carry >> out for this issue, or does it need someone who understands the >> code a bit better? > > It's not a debugging problem, but rather a design issue. The > current design makes use of the first AVA of the filter to decide > how two filters are compared. In your case, the first component is > common to all filters, so only the first occurrence of a search with > that template can be cached. This fact, to my knowledge, is > undocumented, but there's little to do except redesign this weighing > criterium. As I already pointed out, you need to make the most > significant filter AVA appear first in your filter template. Unless > anyone voluteers for a complete redesign [*] of this portion of > slapo-pcache(5), I take your ITS as a request to document this > aspect of template design. > > p. > > [*] a complete redesign could also get rid of strict ordering of > filter AVAs, allow "static" portions of the filter (something like > (&(objectClass=person)(uid=)) and so) and other relatively > unfriendly aspects of slapo-pcache(5) configuration. The problem with changing the ordering in the template is that it then doesn't match the real lookups that occur and so the entries aren't cached - this is something over which I have no control - e.g. queries generated by 'ls -l', or by somebody logging into the machine, etc, etc. This is why we have the filters this way. e.g. sshing into one of our scientific linux 5.2 hosts generates the following lookups: [sybies]toby: grep 'query template' ~/tmp/pcache-login |cut -d' ' -f13| sort|uniq -c 1 (&(objectClass=)(cn=)) 2 (&(objectClass=)(|(memberUid=)(uniqueMember=))) 28 (&(objectClass=)(uid=)) 5 (&(objectClass=)(uidNumber=)) 26 (&(objectClass=)(uniqueMember=)) [sybies]toby: Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 04 Nov '08

04 Nov '08

toby(a)inf.ed.ac.uk wrote: > Hi there, is there any further debugging I could usefully carry out > for this issue, or does it need someone who understands the code a bit > better? It's not a debugging problem, but rather a design issue. The current design makes use of the first AVA of the filter to decide how two filters are compared. In your case, the first component is common to all filters, so only the first occurrence of a search with that template can be cached. This fact, to my knowledge, is undocumented, but there's little to do except redesign this weighing criterium. As I already pointed out, you need to make the most significant filter AVA appear first in your filter template. Unless anyone voluteers for a complete redesign [*] of this portion of slapo-pcache(5), I take your ITS as a request to document this aspect of template design. p. [*] a complete redesign could also get rid of strict ordering of filter AVAs, allow "static" portions of the filter (something like (&(objectClass=person)(uid=)) and so) and other relatively unfriendly aspects of slapo-pcache(5) configuration. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5787) few improvements
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Few improvements here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-cf-2008-11-04.tar.gz> (allow digit substitutions, introduced to avoid collisions). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5789) using IP address in CN with GnuTLS
by leva＠ecentrum.hu 04 Nov '08

04 Nov '08

Full_Name: LÉVAI Dániel Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.131.56.68) I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. The GnuTLS version is 2.4.2. So I'm having a lot of problems using OpenLDAP with GnuTLS, and I've decided to take another route in troubleshooting; I've recreated my cert/key pair, using my machine's ip address in the CN field. The weirdest thing happened: $ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://192.168.1.3 ldap_url_parse_ext(ldap://192.168.1.3) ldap_create ldap_url_parse_ext(ldap://192.168.1.3:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.1.3:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x6120a0 msgid 1 wait4msg ld 0x6120a0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120a0 msgid 1 all 1 ** ld 0x6120a0 Connections: * host: 192.168.1.3 port: 389 (default) refcnt: 2 status: Connected last used: Fri Oct 31 22:36:46 2008 ** ld 0x6120a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120a0 request count 1 (abandoned 0) ** ld 0x6120a0 Response Queue: Empty ld 0x6120a0 response count 0 ldap_chkResponseList ld 0x6120a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120a0 NULL ldap_int_select read1msg: ld 0x6120a0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120a0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120a0 0 new referrals read1msg: mark request completed, ld 0x6120a0 msgid 1 request done: ld 0x6120a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3). ldap_err2string ldap_start_tls: Connect error (-11) So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? And please allow me include some additional information, which was told me by Philip Guenther on openldap-software@: "It appears the routine used with GNUtls refuses to match IP addresses against a CN subjects component, thus explaining that weird message. (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname doesn't look like an IPv6 or IPv4 address, while the subject CN test needs 'len1' to be the same as the length of the CN value.)" Daniel

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 03 Nov '08

03 Nov '08

ando(a)sys-net.it wrote: > richton(a)nbcs.rutgers.edu wrote: > >> Rare connection.c assertion during test008s of RE24. Here are three different >> examples: > >> [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn >> = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > > >> [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = >> 0x1005c1b98), line 187 in "rww.c" > >> [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = >> 0x1005c1b98), line 185 in "rww.c" > > > Sorry, I overlooked the fact that all those issues are occurring from > within back-monitor. In all cases, it's within code that loops through > the connection array using connection_{first,next,close}(). Apparently, > those calls are used in the right way. Can you print more information > about those connections? E.g. c->c_struct_state, and *index from within > connection_next()? Or even better, the whole *c structure? Looks like it may be related to #5586. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs