openldap-bugs November 2015

openldap-bugs@openldap.org

25 participants
61 discussions

Re: (ITS#8304) LMDB mdb_del data loss in a cursor
by hyc＠symas.com 09 Nov '15

09 Nov '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c > Submission from: (NULL) (71.119.103.68) > > > I have a new repro of an ITS#8264 and ITS#8299-like situation, but with > different input data. > > The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. > > Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts > the > database. In this case, mdb_del incorrectly removes one extra key (a key > prefixed with 03000000000000003a...). Thanks. Fixed in git. This appears to have been broken by commit d9423e13f85bac7c33083a4b872c022d18a41232 > On a related note, I have switched to mdb_cursor_del whenever possible, but > there are a couple of situations where clients of my library only have the key > during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting > you know that I took your advice from earlier, but must still use mdb_del here > and there. > > -- -- 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#8304) LMDB mdb_del data loss in a cursor
by malyn＠strangeGizmo.com 09 Nov '15

09 Nov '15

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c Submission from: (NULL) (71.119.103.68) I have a new repro of an ITS#8264 and ITS#8299-like situation, but with different input data. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the database. In this case, mdb_del incorrectly removes one extra key (a key prefixed with 03000000000000003a...). On a related note, I have switched to mdb_cursor_del whenever possible, but there are a couple of situations where clients of my library only have the key during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting you know that I took your advice from earlier, but must still use mdb_del here and there.

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

Michael Alyn Miller wrote: >>>> Another issue similar to ITS#8264 and ITS#8299, but this time using >>>> mdb_cursor_del inside of the cursor causes corruption. mdb_del >>>> causes corruption as well, but this is the first time that I have >>>> seen mdb_cursor_del do the wrong thing. >>>> >>>> In this case, mdb_cursor_del incorrectly removes one extra key (a key >>>> prefixed with 0c000000000000003a...) in addition to correctly >>>> removing all of the keys that begin with 0d000000000000003a. >>>> >>>> mdb_del does not remove that extra key, but instead fails to remove >>>> two 0d000000000000003a keys that should have been removed. >>>> >>>> I am not sure if these are two different bugs or if they are caused >>>> by the same underlying issue. >>> >>> Similar reason, two different mistakes. Fixed now in git. >>>> >>>> mdb_cursor_del performs correctly on subsequent runs if you do *not* >>>> remove the database between tests, whereas mdb_del continues to fail, >>>> but stabilizes on a different set of results after the first run. >> >> For future reference, here's a patch to your test program that also checks for >> cursors pointed adjacent to the item being deleted. The previous fix was >> missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG >> for the mdb_cursor_chk() function to be defined. > > Just to confirm, are you saying that this is something that I should > include only in the test harness, or should these checks be in my actual library as well? That was primarily a note for *myself* or anyone who may need to research this issue in the future. Building LMDB with -DMDB_DEBUG is something that we only do for test/debug efforts, not something that any user code should ever worry about. So no, I was not saying there was any particular action you should take. Merely an FYI on how I verified the fix. > Thank you for taking the time to work through these bugs and address all > of the various edge cases. I really appreciate the help. I stand behind my code. > Michael Alyn Miller > -- -- 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#8300) LMDB mdb_cursor_del data loss
by malyn＠strangegizmo.com 06 Nov '15

06 Nov '15

> >> Another issue similar to ITS#8264 and ITS#8299, but this time using > >> mdb_cursor_del inside of the cursor causes corruption. mdb_del > >> causes corruption as well, but this is the first time that I have > >> seen mdb_cursor_del do the wrong thing. > >> > >> In this case, mdb_cursor_del incorrectly removes one extra key (a key > >> prefixed with 0c000000000000003a...) in addition to correctly > >> removing all of the keys that begin with 0d000000000000003a. > >> > >> mdb_del does not remove that extra key, but instead fails to remove > >> two 0d000000000000003a keys that should have been removed. > >> > >> I am not sure if these are two different bugs or if they are caused > >> by the same underlying issue. > > > > Similar reason, two different mistakes. Fixed now in git. > >> > >> mdb_cursor_del performs correctly on subsequent runs if you do *not* > >> remove the database between tests, whereas mdb_del continues to fail, > >> but stabilizes on a different set of results after the first run. >=20 > For future reference, here's a patch to your test program that also check= s for > cursors pointed adjacent to the item being deleted. The previous fix was > missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG > for the mdb_cursor_chk() function to be defined. Just to confirm, are you saying that this is something that I should includ= e only in the test harness, or should these checks be in my actual library = as well? Thank you for taking the time to work through these bugs and address all of= the various edge cases. I really appreciate the help. Michael Alyn Miller

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

This is a multi-part message in MIME format. --------------090509040809000501070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > malyn(a)strangeGizmo.com wrote: >> Full_Name: Michael Alyn Miller >> Version: Git head >> OS: Windows 8.1 x64, NixOS 14.12 x64 >> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c >> Submission from: (NULL) (96.251.78.237) >> >> >> Another issue similar to ITS#8264 and ITS#8299, but this time using >> mdb_cursor_del inside of the cursor causes corruption. mdb_del causes >> corruption as well, but this is the first time that I have seen mdb_cursor_del >> do the wrong thing. >> >> In this case, mdb_cursor_del incorrectly removes one extra key (a key >> prefixed with 0c000000000000003a...) in addition to correctly removing all of >> the keys that begin with 0d000000000000003a. >> >> mdb_del does not remove that extra key, but instead fails to remove two >> 0d000000000000003a keys that should have been removed. >> >> I am not sure if these are two different bugs or if they are caused by the same >> underlying issue. > > Similar reason, two different mistakes. Fixed now in git. >> >> mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the >> database between tests, whereas mdb_del continues to fail, but stabilizes on a >> different set of results after the first run. For future reference, here's a patch to your test program that also checks for cursors pointed adjacent to the item being deleted. The previous fix was missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG for the mdb_cursor_chk() function to be defined. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------090509040809000501070508 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" --- /tmp/michaelalynmiller-151104.c 2015-11-06 10:38:44.772490173 +0000 +++ michaelalynmiller-151104.c 2015-11-06 10:18:13.000000000 +0000 @@ -3696,10 +3696,10 @@ void remove_collection12(MDB_env *env, MDB_dbi dbi, int delete_with_cursor) { - int rc; + int i, rc; MDB_txn *txn; MDB_val key, data; - MDB_cursor *cursor; + MDB_cursor *cursor, *cup, *cdn; E(mdb_txn_begin(env, NULL, 0, &txn)); @@ -3710,6 +3710,8 @@ E(mdb_del(txn, dbi, &key, &data)); E(mdb_cursor_open(txn, dbi, &cursor)); + E(mdb_cursor_open(txn, dbi, &cup)); + E(mdb_cursor_open(txn, dbi, &cdn)); key.mv_size = 8+1; key.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00:"; @@ -3717,13 +3719,19 @@ data.mv_data = NULL; E(mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE)); - for (;;) { + for (i=0;;i++) { data.mv_size = 8+1; data.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00;"; if (mdb_cmp(txn, dbi, &data, &key) < 0) { break; } + E(mdb_cursor_get(cup, &key, &data, MDB_SET)); + E(mdb_cursor_get(cdn, &key, &data, MDB_SET)); + mdb_cursor_get(cup, NULL, NULL, MDB_NEXT); + mdb_cursor_get(cdn, NULL, NULL, MDB_PREV); + + printf("Deleting %d\n", i); if (delete_with_cursor) { E(mdb_cursor_del(cursor, 0)); } else { @@ -3731,6 +3739,9 @@ data.mv_data = NULL; E(mdb_del(txn, dbi, &key, &data)); } + mdb_cursor_chk(cursor); + mdb_cursor_chk(cup); + mdb_cursor_chk(cdn); rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT); if (rc == MDB_NOTFOUND) { --------------090509040809000501070508--

1 0

Re: Re: (ITS#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

This is a multi-part message in MIME format. ------=_001_NextPart715611200672_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBRdWFuYWgsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSwgSSdsbCBjb250YWN0IHdpdGgg b3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9yZyB0byBmaXggdGhpcyBpc3N1ZS4NCg0KDQoN Cg0KVGhhbmtzICYgQmVzdCBSZWdhcmRzIA0KQmVuIEh1YW5nL0lDSUxTWlggDQo4Ni0wNzU1LTg4 Mjg1MzcwLWV4dDExMTYuDQogDQpGcm9tOiBRdWFuYWggR2lic29uLU1vdW50DQpEYXRlOiAyMDE1 LTExLTA2IDAxOjQxDQpUbzogYmVuaHVhbmc7IG9wZW5sZGFwLWl0cw0KU3ViamVjdDogUmU6IChJ VFMjODMwMikgVGhlIGNoYWluLXRscyBmYWlsdXJlDQotLU9uIFRodXJzZGF5LCBOb3ZlbWJlciAw NSwgMjAxNSAxMToyNyBBTSArMDAwMCBiZW5odWFuZ0BpY2lsLm5ldCB3cm90ZToNCiANCj4gRnVs bF9OYW1lOiBCZW4gSHVhbmcNCj4gVmVyc2lvbjogMi40LjM3DQo+IE9TOiBVYnVudHUgMTIuMDQu NCBMVFMNCj4gVVJMOiBmdHA6Ly9mdHAub3BlbmxkYXAub3JnL2luY29taW5nLw0KPiBTdWJtaXNz aW9uIGZyb206IChOVUxMKSAoMjAyLjEzMC44Ni4xMzApDQogDQpQbGVhc2UgdXNlIGEgY3VycmVu dCByZWxlYXNlLiAgVXNhZ2UgcXVlc3Rpb25zIHN1Y2ggYXMgeW91cnMgc2hvdWxkIGFsc28gYmUg DQpkaXJlY3RlZCB0byBvcGVubGRhcC10ZWNobmljYWxAb3BlbmxkYXAub3JnIHJhdGhlciB0aGFu IHRoZSBJVFMgc3lzdGVtLCANCndoaWNoIGlzIGZvciBidWcgcmVwb3J0cyBhZ2FpbnN0IGN1cnJl bnQgY29kZS4NCiANClRoaXMgSVRTIHdpbGwgYmUgY2xvc2VkLg0KIA0KVGhhbmtzLA0KUXVhbmFo DQogDQogDQotLQ0KIA0KUXVhbmFoIEdpYnNvbi1Nb3VudA0KUmVsZWFzZSBhbmQgUUEgRW5naW5l ZXINCjxodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZz4NCg== ------=_001_NextPart715611200672_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: = 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 12pt; font= -family: Calibri; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><= body>=0A<div><span></span>Dear <span style=3D"font-size: 12pt; line-h= eight: 1.5; background-color: window;">Quanah,</span></div><div><span styl= e=3D"font-size: 12pt; line-height: 1.5; background-color: window;"><br></s= pan></div><div>Thanks for your reply, I'll contact with <span style= =3D"font-size: 12pt; line-height: 1.5; background-color: window;"></span><= a href=3D"mailto:openldap-technical@openldap.org" style=3D"font-size: 12pt= ; line-height: 1.5; background-color: window;">openldap-technical@openldap= .org</a><span style=3D"font-size: 12pt; line-height: 1.5; background-color= : window;"> to fix this issue.</span></div>=0A<div><br></div><hr styl= e=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"lef= t">=0A<div><span><div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D= "" color:=3D"" rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,= =3D"" font-weight:=3D"" normal;=3D"" font-style:=3D"" normal;text-decorati= on:=3D"" none;'=3D""><b><font face=3D"Calibri Light"><br></font></b></span= ></div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D"" color:=3D"" = rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,=3D"" font-weig= ht:=3D"" normal;=3D"" font-style:=3D"" normal;text-decoration:=3D"" none;'= =3D""><b><div><b style=3D"font-size: 12pt; line-height: 1.5; background-co= lor: window;"><font>Thanks & Best Regards </font></b></div>Ben Hu= ang/ICILSZX=0A<br>86-0755-88285370-ext1116.</b></span></span></div>=0A<blo= ckquote style=3D"margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"= ><div> </div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt= ;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT= : 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efef= ef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href= =3D"mailto:quanah@openldap.org">Quanah Gibson-Mount</a></div><div><b>Date:= </b> 2015-11-06 01:41</div><div><b>To:</b> <a href=3D"mailt= o:benhuang@icil.net">benhuang</a>; <a href=3D"mailto:openldap-its@openldap= .org">openldap-its</a></div><div><b>Subject:</b> Re: (ITS#8302) The c= hain-tls failure</div></div></div><div><div>--On Thursday, November 05, 20= 15 11:27 AM +0000 benhuang(a)icil.net wrote:</div>=0A<div> </div>=0A<di= v>> Full_Name: Ben Huang</div>=0A<div>> Version: 2.4.37</div>=0A<div= >> OS: Ubuntu 12.04.4 LTS</div>=0A<div>> URL: ftp://ftp.openldap.org= /incoming/</div>=0A<div>> Submission from: (NULL) (202.130.86.130)</div= >=0A<div> </div>=0A<div>Please use a current release.  Usage que= stions such as yours should also be </div>=0A<div>directed to openldap-tec= hnical(a)openldap.org rather than the ITS system, </div>=0A<div>which is for= bug reports against current code.</div>=0A<div> </div>=0A<div>This I= TS will be closed.</div>=0A<div> </div>=0A<div>Thanks,</div>=0A<div>Q= uanah</div>=0A<div> </div>=0A<div> </div>=0A<div>--</div>=0A<div= > </div>=0A<div>Quanah Gibson-Mount</div>=0A<div>Release and QA Engin= eer</div>=0A<div><http://www.openldap.org></div>=0A</div></blockquot= e>=0A</body></html> ------=_001_NextPart715611200672_=------

1 0

Re: (ITS#8302) The chain-tls failure
by quanah＠openldap.org 05 Nov '15

05 Nov '15

--On Thursday, November 05, 2015 11:27 AM +0000 benhuang(a)icil.net wrote: > Full_Name: Ben Huang > Version: 2.4.37 > OS: Ubuntu 12.04.4 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.130.86.130) Please use a current release. Usage questions such as yours should also be directed to openldap-technical(a)openldap.org rather than the ITS system, which is for bug reports against current code. This ITS will be closed. Thanks, Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

(ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 05 Nov '15

05 Nov '15

Full_Name: Nadezhda Ivanova Version: slapd 2.X OS: URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch Submission from: (NULL) (78.83.54.234) This is an asynchronous version of the meta back-end. The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by hyc＠symas.com 05 Nov '15

05 Nov '15

ryan(a)nardis.ca wrote: > On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >> Hi, the following will assert in liblber on i386 (and it should be possible to >> craft a similar one for 64bit, I think): >> >> echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . > > ITYM dtest? > > slapd's sane default setting for sb_max_incoming appears to mitigate > most of the potential security impact of this one. Agreed. But I guess we need to reject any len values that exceed the range of a signed ber_len_t, since many liblber functions can only return a ber_slen_t result. -- -- 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#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

Full_Name: Ben Huang Version: 2.4.37 OS: Ubuntu 12.04.4 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.130.86.130) Two servers: Provider (A public IP) and Consumer (A private IP) both running slap 2.4.37 and ubuntu 12.04. Replica is a replication partner of Provider using syncrepl. Replication and TLS is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the Privder, I cannot enable TLS from the consumer to the ldap Provider. Here is my overlay config using the rootDN and TLS (on Replica): ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://provider.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=ufreight,dc=com" credentials="password" keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 With above configuration, I run following command is ok: #ldapsearch -xLLL -H ldap://ldap-u1.ufreight.com -ZZ uid=testuser dn dn: uid=testuser,ou=People,dc=ufreight,dc=com But below errors occurred when I try to add an entry on consumer. ldapadd -x -D "cn=admin,dc=ufreight,dc=com" -w password -f add_user.ldif -ZZ adding new entry "uid=test,ou=People,dc=ufreight,dc=com" ldap_add: Server is unavailable (52) Consumer LDAP logs: No 5 1 19:12:28 consumer slapd[6575]: conn=1005 fd=16 ACCEPT from IP=127.0.0.1:41018 (IP=0.0.0.0:389) Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 STARTTLS Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 RESULT oid= err=0 text= Nov 5 19:12:30 consumer slapd[6575]: conn=1005 fd=16 TLS established tls_ssf=128 ssf=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,%c=com" method=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,dc=com" mech=SIMPLE ssf=0 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 RESULT tag=97 err=0 text= Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 ADD dn="uid=test,ou=People,dc=ufreight,dc=com" Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 RESULT tag=105 err=52 text= Nov 5 19:12:33 consumer slapd[6575]: conn=1005 op=3 UNBIND Nov 5 19:12:33 consumer slapd[6575]: conn=1005 fd=16 closed Provider LDAP logs: Nov 5 19:11:18 provider slapd[17011]: conn=312743 fd=13 ACCEPT from IP=140.207.172.138:39551 (IP=0.0.0.0:389) Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 STARTTLS Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 RESULT oid= err=0 text= Nov 5 19:11:19 provider slapd[17011]: conn=312743 fd=13 closed (TLS negotiation failure) Any suggestion what cause TLS negotiation failure? Thank you very much.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2015