openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8973) Error with domainScope control when using C# LDAP API
by hyc＠symas.com 06 Feb '19

06 Feb '19

hyc(a)symas.com wrote: > clement.oudot(a)worteks.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.47 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.250.130.213) >> >> >> Hello, >> >> after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : > > The code in controls.c is correct. The DomainScope control does not take a value, > so the value is required to be NULL. Microsoft spec https://msdn.microsoft.com/en-us/library/cc223348.aspx "When sending this control to the DC, the controlValue field of the Control structure is omitted." -- -- 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#8973) Error with domainScope control when using C# LDAP API
by hyc＠symas.com 06 Feb '19

06 Feb '19

clement.oudot(a)worteks.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.47 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.250.130.213) > > > Hello, > > after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : The code in controls.c is correct. The DomainScope control does not take a value, so the value is required to be NULL. > ---- > $auth = [System.DirectoryServices.AuthenticationTypes]::FastBind > $de = New-Object System.DirectoryServices.DirectoryEntry($DN,$userReferentiel, > $passwordReferentiel, $auth) > ---- > > The log in OpenLDAP 2.4.47 : > ---- > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 fd=17 ACCEPT from > IP=10.10.2.163:47304 (IP=0.0.0.0:390) > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 BIND > dn="uid=ADPassword,ou=configuration,dc=referentiel,dc=local" method=128 > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 BIND > dn="uid=ADPassword,ou=configuration,dc=referentiel,dc=local" mech=SIMPLE ssf=0 > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 RESULT tag=97 err=0 text= > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SRCH > base="dc=referentiel,dc=local" scope=0 deref=0 filter="(objectClass=*)" > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SRCH attr=objectClass > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SEARCH RESULT tag=101 err=0 > nentries=1 text= > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SRCH base="" scope=0 > deref=0 filter="(objectClass=*)" > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SRCH attr=subschemaSubentry > dsServiceName namingContexts defaultNamingContext schemaNamingContext > configurationNamingContext rootDomainNamingContext supportedControl > supportedLDAPVersion supportedLDAPPolicies supportedSASLMechanisms dnsHostName > ldapServiceName serverName supportedCapabilities > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SEARCH RESULT tag=101 err=0 > nentries=1 text= > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=3 SEARCH RESULT tag=101 err=2 > nentries=0 text=domainScope control value not absent > Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=3 do_search: get_ctrls > failed > ---- > > The behavior change is related to the fix of ITS#8840 : > www.openldap.org/its/index.cgi/Software Bugs?id=8840 > > I did not see how to change the C# code, are we sure that the fix of ITS#8840 is > valid? > > -- -- 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#8973) Error with domainScope control when using C# LDAP API
by clement.oudot＠worteks.com 06 Feb '19

06 Feb '19

Full_Name: Clement OUDOT Version: 2.4.47 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.250.130.213) Hello, after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : ---- $auth = [System.DirectoryServices.AuthenticationTypes]::FastBind $de = New-Object System.DirectoryServices.DirectoryEntry($DN,$userReferentiel, $passwordReferentiel, $auth) ---- The log in OpenLDAP 2.4.47 : ---- Feb 5 18:21:03 anteros slapd[30762]: conn=1577 fd=17 ACCEPT from IP=10.10.2.163:47304 (IP=0.0.0.0:390) Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 BIND dn="uid=ADPassword,ou=configuration,dc=referentiel,dc=local" method=128 Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 BIND dn="uid=ADPassword,ou=configuration,dc=referentiel,dc=local" mech=SIMPLE ssf=0 Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=0 RESULT tag=97 err=0 text= Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SRCH base="dc=referentiel,dc=local" scope=0 deref=0 filter="(objectClass=*)" Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SRCH attr=objectClass Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SRCH attr=subschemaSubentry dsServiceName namingContexts defaultNamingContext schemaNamingContext configurationNamingContext rootDomainNamingContext supportedControl supportedLDAPVersion supportedLDAPPolicies supportedSASLMechanisms dnsHostName ldapServiceName serverName supportedCapabilities Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=3 SEARCH RESULT tag=101 err=2 nentries=0 text=domainScope control value not absent Feb 5 18:21:03 anteros slapd[30762]: conn=1577 op=3 do_search: get_ctrls failed ---- The behavior change is related to the fix of ITS#8840 : www.openldap.org/its/index.cgi/Software Bugs?id=8840 I did not see how to change the C# code, are we sure that the fix of ITS#8840 is valid?

1 0

RE: (ITS#8972) Performance/freezing issues using NTDLL on WindowsServer on Azure
by kriszyp＠gmail.com 05 Feb '19

05 Feb '19

--_22B17C00-48BC-46BE-A758-3013CC9A68A3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Oh wow, this is just a matter of me using the wrong LMDB version? I had no = idea I wasn=E2=80=99t using the release version. I=E2=80=99ve been using ht= tps://github.com/Venemo/node-lmdb, which includes LMDB directly in it, and = had assumed that the version number in the code implied a release. I can pu= t together a PR for that project to get it on the right version. Thank you so much the pointer, I appreciate! And thank you so much for the = great software, its a fantastic package! Thanks, Kris From: Howard Chu Sent: February 5, 2019 12:03 PM To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8972) Performance/freezing issues using NTDLL on WindowsS= erver on Azure kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.70 > OS: Windows Server 2012 R2 > URL:=20 > Submission from: (NULL) (71.199.6.148) I guess Windows users are never happy. Note that you're using the LMDB work-in-progress code. You ought to be usin= g the LMDB 0.9 release branch, which just uses Win32. The fact is that you get optimal performance by using LMDB as originally de= signed and documented - choose as large a mapsize as possible and then forget abou= t it. Preallocation is always more efficient than incremental growth. Clearly Windows will struggle to allocate disk space to grow files and addr= ess space to grow maps while there's competing system activity occurring, and t= his problem is worse when running under a hypervisor. This is the reason we nev= er merged the NTDLL code into the release branch; we knew from the outset that= it would destroy performance. https://openldap.org/lists/openldap-technical/201511/msg00107.html As a general rule, we're opposed to adding platform-specific API options to= LMDB. The API is supposed to be uniform across all supported platforms. If you wa= nt to submit a patch for compile-time selection of this feature, I guess that cou= ld work. As it is, LMDB is clearly not going to be a preinstalled Windows DLL = so it should be being built privately for every app that uses it anyway, so th= is shouldn't cause compatibility issues. > We have experienced significant performance issues in the form of strange= pauses > or freezing of any processes that are using our LMDB databases. These pau= ses are > periodic, often every few minutes, and typically completely freeze a proc= ess for > about 5 seconds, sometimes less, sometimes as much as a minute. They ofte= n occur > when the process is completely idle (we have a sleep timer to monitor for= them), > but we also see a lot of unusually large pauses on commits too. We have n= ever > been able to reproduce any of these issues with our local machines runnin= g > Windows 10, only on the virtual Azure Windows servers. >=20 > After weeks of investigation, we finally realized that all of these stran= ge > performance issues seemed to be due to the use of NTDLL for memory mappin= g. I > swapped out the NtCreateSection/NtMapViewOfSection calls for standard Win= 32 > CreateFileMapping/MapViewOfFile calls to create the memory map, and sudde= nly > these issues went away, and performance dramatically improved. Making thi= s > switch does mean you lose the progressive file allocation functionality o= f > NtCreateSection, but this is a small price to pay for the vast performanc= e > benefit of using standard file mapping. >=20 > Anyway, my request is to simply to provide an option to use CreateFileMap= ping > API instead of NtCreateSection. I recognize that the NTDLL based APIs may= be > more convenient for many users, but an option to use the standard APIs, e= ven if > it means the entire map is pre-allocated in the file size, is well worth = it for > the gains. I also recognize that Windows isn't the first choice of LMDB, = but > performance with these standard APIs is very good. >=20 > I'd be happy to work on putting together a branch/pull request to address= this. > However, your repository is a little different than typical github reposi= tories, > so I wanted to know if that was doable, and if there was a proper way to = submit > a PR, or if it needs to be submitted through this ticket system as a patc= h. http://www.openldap.org/devel/contributing.html --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --_22B17C00-48BC-46BE-A758-3013CC9A68A3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>Oh wow, this is just a matter of me = using the wrong LMDB version? I had no idea I wasn=E2=80=99t using the rele= ase version. I=E2=80=99ve been using <a href=3D"https://github.com/Venemo/n= ode-lmdb">https://github.com/Venemo/node-lmdb</a>, which includes LMDB dire= ctly in it, and had assumed that the version number in the code implied a r= elease. I can put together a PR for that project to get it on the right ver= sion.Thank you so much the pointer, I appreciate! = And thank you so much for the great software, its a fantastic package!<= p class=3DMsoNormal><o:p> </o:p>Thanks, Kr= is<o:p> </o:p><div style=3D'mso-element:p= ara-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm= 0cm 0cm'>From: <= /b><a href=3D"mailto:hyc@symas.com">Howard Chu</a> Sent: February= 5, 2019 12:03 PM To: <a href=3D"mailto:kriszyp@gmail.com">kriszy= p(a)gmail.com</a>; <a href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its@= OpenLDAP.org</a> Subject: Re: (ITS#8972) Performance/freezing iss= ues using NTDLL on WindowsServer on Azure</div><o:= p> </o:p>kriszyp(a)gmail.com wrote:> Full_Name: Kristopher William Zyp> Version: LMDB 0.9.70> OS: Windows Server = 2012 R2> URL: > Sub= mission from: (NULL) (71.199.6.148)<o:p> </o:= p>I guess Windows users are never happy.<o:p> </o:p>Note that you're u= sing the LMDB work-in-progress code. You ought to be using theLMDB 0.9 release branch, which just uses Win32.<o:p> </o:p>The fact is that you ge= t optimal performance by using LMDB as originally designedand documented - choose as large a mapsize as possible and then for= get about it.Preallocation is always more efficien= t than incremental growth.<o:p> </o:p>Clearly Windows will struggle to allocate disk space to g= row files and addressspace to grow maps while ther= e's competing system activity occurring, and thisp= roblem is worse when running under a hypervisor. This is the reason we neve= rmerged the NTDLL code into the release branch; we= knew from the outset that itwould destroy perform= ance.<o:p> </o:p>htt= ps://openldap.org/lists/openldap-technical/201511/msg00107.html<o:p> </o:p>As a general rule, w= e're opposed to adding platform-specific API options to LMDB.The API is supposed to be uniform across all supported platfor= ms. If you want tosubmit a patch for compile-time = selection of this feature, I guess that couldwork.= As it is, LMDB is clearly not going to be a preinstalled Windows DLL so</p= >it should be being built privately for every app that= uses it anyway, so thisshouldn't cause compatibil= ity issues.<o:p> </o:p>> We have experienced significant performance issues in the form of s= trange pauses> or freezing of any processes tha= t are using our LMDB databases. These pauses are&g= t; periodic, often every few minutes, and typically completely freeze a pro= cess for> about 5 seconds, sometimes less, some= times as much as a minute. They often occur> wh= en the process is completely idle (we have a sleep timer to monitor for the= m),> but we also see a lot of unusually large p= auses on commits too. We have never> been able = to reproduce any of these issues with our local machines running> Windows 10, only on the virtual Azure Windows servers.</= p>> > After weeks of in= vestigation, we finally realized that all of these strange> performance issues seemed to be due to the use of NTDLL for me= mory mapping. I> swapped out the NtCreateSectio= n/NtMapViewOfSection calls for standard Win32> = CreateFileMapping/MapViewOfFile calls to create the memory map, and suddenl= y> these issues went away, and performance dram= atically improved. Making this> switch does mea= n you lose the progressive file allocation functionality of> NtCreateSection, but this is a small price to pay for the vas= t performance> benefit of using standard file m= apping.> > Anyway, = my request is to simply to provide an option to use CreateFileMapping<p= class=3DMsoNormal>> API instead of NtCreateSection. I recognize that th= e NTDLL based APIs may be> more convenient for = many users, but an option to use the standard APIs, even if> it means the entire map is pre-allocated in the file size, is= well worth it for> the gains. I also recognize= that Windows isn't the first choice of LMDB, but&= gt; performance with these standard APIs is very good.> > I'd be happy to work on putting toge= ther a branch/pull request to address this.> Ho= wever, your repository is a little different than typical github repositori= es,> so I wanted to know if that was doable, an= d if there was a proper way to submit> a PR, or= if it needs to be submitted through this ticket system as a patch.<o:p> </o:p>http://www.openl= dap.org/devel/contributing.html<o:p> </o:p></= p>-- =C2=A0=C2=A0-- Howard Ch= u=C2=A0 CTO, Symas Corp.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.symas.com=C2=A0 Director, Highland Sun=C2=A0=C2=A0=C2=A0=C2=A0 http://highlan= dsun.com/hyc/ =C2=A0Chief Architect, OpenLDAP=C2= =A0 http://www.openldap.org/project/<o:p> </o= :p></div></body></html>= --_22B17C00-48BC-46BE-A758-3013CC9A68A3_--

1 0

Re: (ITS#8972) Performance/freezing issues using NTDLL on Windows Server on Azure
by hyc＠symas.com 05 Feb '19

05 Feb '19

kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.70 > OS: Windows Server 2012 R2 > URL: > Submission from: (NULL) (71.199.6.148) I guess Windows users are never happy. Note that you're using the LMDB work-in-progress code. You ought to be using the LMDB 0.9 release branch, which just uses Win32. The fact is that you get optimal performance by using LMDB as originally designed and documented - choose as large a mapsize as possible and then forget about it. Preallocation is always more efficient than incremental growth. Clearly Windows will struggle to allocate disk space to grow files and address space to grow maps while there's competing system activity occurring, and this problem is worse when running under a hypervisor. This is the reason we never merged the NTDLL code into the release branch; we knew from the outset that it would destroy performance. https://openldap.org/lists/openldap-technical/201511/msg00107.html As a general rule, we're opposed to adding platform-specific API options to LMDB. The API is supposed to be uniform across all supported platforms. If you want to submit a patch for compile-time selection of this feature, I guess that could work. As it is, LMDB is clearly not going to be a preinstalled Windows DLL so it should be being built privately for every app that uses it anyway, so this shouldn't cause compatibility issues. > We have experienced significant performance issues in the form of strange pauses > or freezing of any processes that are using our LMDB databases. These pauses are > periodic, often every few minutes, and typically completely freeze a process for > about 5 seconds, sometimes less, sometimes as much as a minute. They often occur > when the process is completely idle (we have a sleep timer to monitor for them), > but we also see a lot of unusually large pauses on commits too. We have never > been able to reproduce any of these issues with our local machines running > Windows 10, only on the virtual Azure Windows servers. > > After weeks of investigation, we finally realized that all of these strange > performance issues seemed to be due to the use of NTDLL for memory mapping. I > swapped out the NtCreateSection/NtMapViewOfSection calls for standard Win32 > CreateFileMapping/MapViewOfFile calls to create the memory map, and suddenly > these issues went away, and performance dramatically improved. Making this > switch does mean you lose the progressive file allocation functionality of > NtCreateSection, but this is a small price to pay for the vast performance > benefit of using standard file mapping. > > Anyway, my request is to simply to provide an option to use CreateFileMapping > API instead of NtCreateSection. I recognize that the NTDLL based APIs may be > more convenient for many users, but an option to use the standard APIs, even if > it means the entire map is pre-allocated in the file size, is well worth it for > the gains. I also recognize that Windows isn't the first choice of LMDB, but > performance with these standard APIs is very good. > > I'd be happy to work on putting together a branch/pull request to address this. > However, your repository is a little different than typical github repositories, > so I wanted to know if that was doable, and if there was a proper way to submit > a PR, or if it needs to be submitted through this ticket system as a patch. http://www.openldap.org/devel/contributing.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

(ITS#8972) Performance/freezing issues using NTDLL on Windows Server on Azure
by kriszyp＠gmail.com 05 Feb '19

05 Feb '19

Full_Name: Kristopher William Zyp Version: LMDB 0.9.70 OS: Windows Server 2012 R2 URL: Submission from: (NULL) (71.199.6.148) We have experienced significant performance issues in the form of strange pauses or freezing of any processes that are using our LMDB databases. These pauses are periodic, often every few minutes, and typically completely freeze a process for about 5 seconds, sometimes less, sometimes as much as a minute. They often occur when the process is completely idle (we have a sleep timer to monitor for them), but we also see a lot of unusually large pauses on commits too. We have never been able to reproduce any of these issues with our local machines running Windows 10, only on the virtual Azure Windows servers. After weeks of investigation, we finally realized that all of these strange performance issues seemed to be due to the use of NTDLL for memory mapping. I swapped out the NtCreateSection/NtMapViewOfSection calls for standard Win32 CreateFileMapping/MapViewOfFile calls to create the memory map, and suddenly these issues went away, and performance dramatically improved. Making this switch does mean you lose the progressive file allocation functionality of NtCreateSection, but this is a small price to pay for the vast performance benefit of using standard file mapping. Anyway, my request is to simply to provide an option to use CreateFileMapping API instead of NtCreateSection. I recognize that the NTDLL based APIs may be more convenient for many users, but an option to use the standard APIs, even if it means the entire map is pre-allocated in the file size, is well worth it for the gains. I also recognize that Windows isn't the first choice of LMDB, but performance with these standard APIs is very good. I'd be happy to work on putting together a branch/pull request to address this. However, your repository is a little different than typical github repositories, so I wanted to know if that was doable, and if there was a proper way to submit a PR, or if it needs to be submitted through this ticket system as a patch.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 04 Feb '19

04 Feb '19

The reason I like handling the problem in tpool is that tpools is fairly isolated, no worries about which bconfig parts are safe from each other. But by all means attack the problem in bconfig too:-) I've pushed a better version to <git://git.uio.no/u/hbf/openldap.git> branch "its8958-re24-task-speeds-v2". And I see how to port this to master after all, if anyone wants this included in OpenLDAP. RE24 tpool is simpler when discusissing the basics, though. -- Hallvard

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 04 Feb '19

04 Feb '19

SSBqdXN0IG5vdGljZWQgdGhhdCBteSB0d28gdGVzdHMgZGlmZmVyIG9uIHRoZSBjYXNpbmVzcyBv ZiB0aGUgdXNlciBuYW1lLCBidXQgdGhhdCdzIG5vdCBzaWduaWZpY2FudC4gIEkgdGVzdGVkIGFn YWluIHRvIGJlIHN1cmUuIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBI b3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMywgMjAx OSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpdEBDQk9SRC5jb20+OyBvcGVubGRhcC1pdHNA T3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUUyM4OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVu Z3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0QGNib3JkLmNvbSB3cm90ZToNCj4gRnVsbF9O YW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuNC4zMA0KPiBPUzogV2luZG93cyAxMA0KPiBV Ukw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzEwdUtnOU5oM0hMaXVP elRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOemJ3QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1 Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44LjQxKQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9w ZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZGF0ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1 ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gDQo+IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQg SSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gcnVubmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9u LCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ2Ugd2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25v dy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z2ggdG8gdHJhY2sgdGhpcyBkb3duIHRoYXQg SSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZm91bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1 dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBdCBzb21lIHBvaW50IG15IGJpbmRpbmdzIGZy b20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZSB1c2VybmFtZSANCj4gb3IgcGFzc3dvcmQg aXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvcnJlY3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0 aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhcHR1cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8g aXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb3V0IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMg dGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtdWx0aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3Ig aW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwcGFyZW50bHkgZG9lcyBub3QgYWNjb21tb2Rh dGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gcmVxdWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBz ZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGljaCBzdWNjZWVkcywgIA0KPiB2YXJpZXMgb25s eSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVs dGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlIGFsbG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQg DQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlcXVlc3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3Ro ID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpcmUgYSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1 ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gYSBsYXRlciB2ZXJzaW9uLg0KPiANCj4gU2Ny ZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZXJlOiANCj4gDQo+IGh0dHBzOi8vZG9jcy5n b29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzSExpdU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcN Cj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNCg0KVGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxl LCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb3B5IGhleCBkdW1wcyBvZiBib3RoIHJlcXVl c3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gSG93YXJkIENodQ0KICBDVE8sIFN5bWFzIENv cnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNvbQ0KICBEaXJlY3RvciwgSGlnaGxhbmQg U3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBP cGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8NCg==

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 03 Feb '19

03 Feb '19

ZnJhbWUgY2FwdHVyZXMgZm9sbG93LiAgTGRhcCBtZXNzYWdlIGJlZ2lucyBhdCBvZmZzZXQgMHgz NiAoYWZ0ZXIgZXRoZXJuZXQsIGlwLCB0Y3AgaGVhZGVycykNCnN1Y2Nlc3M6DQowMCBGRiAwNiAx NiBFNiBFMSAwMCBGRiAwNSAxNiBFNiBFMSAwOCAwMCA0NSAwMCAwMCA1MyA2QiBGRSA0MCAwMCA4 MCAwNiA0RiBGNCAwQSAwMSAyOCAyQSAwQSA3OCAwMiAxMCBENSAwOCAwMSA4NSAzMiBGQiAyQiBF NiA1MCAxNSA0NyBGMSA1MCAxOCAwMSAwMCA5MCA0OCAwMCAwMCAzMCAyOSAwMiAwMSAwMSA2MCAy NCAwMiAwMSAwMyAwNCAxOSA2MyA2RSAzRCA1NSA3MyA2NSA3MiAzMSAyQyA2NCA2MyAzRCA2RCA2 MSA3OCA2MyA3MiA2MyAyQyA2NCA2MyAzRCA2MyA2RiA2RCA4MCAwNCA2OSA2RSA2OSA3NCANCg0K ZmFpbHVyZToNCjAwIEZGIDA2IDE2IEU2IEUxIDAwIEZGIDA1IDE2IEU2IEUxIDA4IDAwIDQ1IDAw IDAwIDVCIDA1IDNBIDQwIDAwIDgwIDA2IEI3IEUyIDBBIDAxIDI4IDJBIDBBIDAxIDAxIDU1IEQ2 IDBBIDAxIDg1IDRGIDREIEYxIEYwIDU3IDJGIDUxIDNDIDUwIDE4IDAxIDAwIDE5IDA2IDAwIDAw IDMwIDg0IDAwIDAwIDAwIDJEIDAyIDAxIDAxIDYwIDg0IDAwIDAwIDAwIDI0IDAyIDAxIDAzIDA0 IDE5IDYzIDZFIDNEIDc1IDczIDY1IDcyIDMxIDJDIDY0IDYzIDNEIDZEIDYxIDc4IDYzIDcyIDYz IDJDIDY0IDYzIDNEIDYzIDZGIDZEIDgwIDA0IDY5IDZFIDY5IDc0IA0KDQpGb3IgeW91ciBjb252 ZW5pZW5jZSAobm90IG5lZWRlZD8pLCBoZXJlIGlzIHRoZSBuZXR3b3JrIG1vbml0b3IgVUkgbGFi ZWxpbmcgZm9yIGVhY2ggZnJhbWUgKHN0YXJ0aW5nIGF0IGxkYXAgbWVzc2FnZSkNCg0Kc3VjY2Vz czoNCiAgRnJhbWU6IE51bWJlciA9IDExOCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gOTcsIE1l ZGlhVHlwZSA9IEVUSEVSTkVUDQorIEV0aGVybmV0OiBFdHlwZSA9IEludGVybmV0IElQIChJUHY0 KSxEZXN0aW5hdGlvbkFkZHJlc3M6WzAwLUZGLTA2LTE2LUU2LUUxXSxTb3VyY2VBZGRyZXNzOlsw MC1GRi0wNS0xNi1FNi1FMV0NCisgSXB2NDogU3JjID0gMTAuMS40MC40MiwgRGVzdCA9IDEwLjEy MC4yLjE2LCBOZXh0IFByb3RvY29sID0gVENQLCBQYWNrZXQgSUQgPSAyNzY0NiwgVG90YWwgSVAg TGVuZ3RoID0gODMNCisgVGNwOiBGbGFncz0uLi5BUC4uLiwgU3JjUG9ydD01NDUzNiwgRHN0UG9y dD1MREFQKDM4OSksIFBheWxvYWRMZW49NDMsIFNlcT04NTUzMjE1NzQgLSA4NTUzMjE2MTcsIEFj az0xMzQzNTcxOTUzLCBXaW49MjU2IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6 IEJpbmQgUmVxdWVzdCwgTWVzc2FnZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBC aW5kIFJlcXVlc3QsIE1lc3NhZ2VJRDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklk OiBTZXF1ZW5jZSBhbmQgU2VxdWVuY2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93 VGFnOiANCiAgICAgICBDbGFzczogICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAg VHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEw MDAwKSAxNg0KICAgLSBBc25MZW46IExlbmd0aCA9IDQxLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAg ICAgIExlbmd0aDogNDEgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAtIE1lc3NhZ2VJRDog MQ0KICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVu aXZlcnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4p IFVuaXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQog ICAgICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwg TGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0 aCA9IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJl cXVlc3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkN CiAgICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24g KDEpDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdW YWx1ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVu Z3RoID0gMA0KICAgICAgTGVuZ3RoOiAzNiBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogIC0g QmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tLCBV c2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgLSBWZXJzaW9u OiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25JZDogSW50ZWdlciB0eXBl IChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAu Li4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1p dGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAgICAtIEFzbkxlbjogTGVu Z3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0aDogMSBieXRlcywgTGVu Z3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAgIC0gTmFtZTogY249VXNl cjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdIZWFkZXI6IA0KICAgICAt IEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAgICAgIC0gTG93VGFnOiAN CiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5 cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDEw MCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAg ICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAgICAgIE9jdGV0U3Ry ZWFtOiBjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhlbnRpY2F0aW9uOiBVc2Vy TmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgIC0gQXV0aGVudGlj YXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2ltcGxlDQogICAgIC0gQXNu SWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAgICAgIC0gTG93VGFnOiAN CiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3BlY2lmaWMgKDIpDQogICAg ICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAgICAgIFRhZ1ZhbHVlOiAo Li4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExlbmd0aE9mTGVuZ3RoID0g MA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAgICAgU2lt cGxlQXV0aGVudGljYXRpb246IGluaXQNCg0KDQpmYWlsdXJlOg0KDQogIEZyYW1lOiBOdW1iZXIg PSAzMCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gMTA1LCBNZWRpYVR5cGUgPSBFVEhFUk5FVA0K KyBFdGhlcm5ldDogRXR5cGUgPSBJbnRlcm5ldCBJUCAoSVB2NCksRGVzdGluYXRpb25BZGRyZXNz OlswMC1GRi0wNi0xNi1FNi1FMV0sU291cmNlQWRkcmVzczpbMDAtRkYtMDUtMTYtRTYtRTFdDQor IElwdjQ6IFNyYyA9IDEwLjEuNDAuNDIsIERlc3QgPSAxMC4xLjEuODUsIE5leHQgUHJvdG9jb2wg PSBUQ1AsIFBhY2tldCBJRCA9IDEzMzgsIFRvdGFsIElQIExlbmd0aCA9IDkxDQorIFRjcDogRmxh Z3M9Li4uQVAuLi4sIFNyY1BvcnQ9NTQ3OTQsIERzdFBvcnQ9TERBUCgzODkpLCBQYXlsb2FkTGVu PTUxLCBTZXE9MTMzMDUwODI3MiAtIDEzMzA1MDgzMjMsIEFjaz0xNDYyNzE4NzgwLCBXaW49MjU2 IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6IEJpbmQgUmVxdWVzdCwgTWVzc2Fn ZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBCaW5kIFJlcXVlc3QsIE1lc3NhZ2VJ RDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklkOiBTZXF1ZW5jZSBhbmQgU2VxdWVu Y2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93VGFnOiANCiAgICAgICBDbGFzczog ICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikg Q29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEwMDAwKSAxNg0KICAgLSBBc25MZW46 IExlbmd0aCA9IDQ1LCBMZW5ndGhPZkxlbmd0aCA9IDQNCiAgICAgIExlbmd0aFR5cGU6IExlbmd0 aE9mTGVuZ3RoID0gNA0KICAgICAgTGVuZ3RoOiA0NSBieXRlcw0KICAtIE1lc3NhZ2VJRDogMQ0K ICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVuaXZl cnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVu aXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQogICAg ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVu Z3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9 IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJlcXVl c3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkNCiAg ICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24gKDEp DQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1 ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVuZ3Ro ID0gNA0KICAgICAgTGVuZ3RoVHlwZTogTGVuZ3RoT2ZMZW5ndGggPSA0DQogICAgICBMZW5ndGg6 IDM2IGJ5dGVzDQogIC0gQmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj11c2VyMSxkYz1t YXhjcmMsZGM9Y29tLCBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBs ZQ0KICAgLSBWZXJzaW9uOiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25J ZDogSW50ZWdlciB0eXBlIChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAg IENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAo Li4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAg ICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0 aDogMSBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAg IC0gTmFtZTogY249dXNlcjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdI ZWFkZXI6IA0KICAgICAtIEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAg ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAo MCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFn VmFsdWU6ICguLi4wMDEwMCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9m TGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDAN CiAgICAgIE9jdGV0U3RyZWFtOiBjbj11c2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhl bnRpY2F0aW9uOiBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0K ICAgIC0gQXV0aGVudGljYXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2lt cGxlDQogICAgIC0gQXNuSWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAg ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3Bl Y2lmaWMgKDIpDQogICAgICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAg ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExl bmd0aE9mTGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3Ro ID0gMA0KICAgICAgU2ltcGxlQXV0aGVudGljYXRpb246IGluaXQNCiAgDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMywgMjAxOSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpdEBD Qk9SRC5jb20+OyBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUUyM4 OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVuZ3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0QGNi b3JkLmNvbSB3cm90ZToNCj4gRnVsbF9OYW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuNC4z MA0KPiBPUzogV2luZG93cyAxMA0KPiBVUkw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9kLzEwdUtnOU5oM0hMaXVPelRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOemJ3 QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44LjQx KQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9wZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZGF0 ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gDQo+ IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQgSSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gcnVu bmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9uLCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ2Ug d2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25vdy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z2gg dG8gdHJhY2sgdGhpcyBkb3duIHRoYXQgSSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZm91 bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBdCBz b21lIHBvaW50IG15IGJpbmRpbmdzIGZyb20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZSB1 c2VybmFtZSANCj4gb3IgcGFzc3dvcmQgaXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvcnJl Y3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhcHR1 cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8gaXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb3V0 IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMgdGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtdWx0 aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IgaW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwcGFy ZW50bHkgZG9lcyBub3QgYWNjb21tb2RhdGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gcmVx dWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBzZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGljaCBz dWNjZWVkcywgIA0KPiB2YXJpZXMgb25seSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0aCBp bmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVsdGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlIGFs bG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQgDQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlcXVl c3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3RoID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpcmUg YSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gYSBs YXRlciB2ZXJzaW9uLg0KPiANCj4gU2NyZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZXJl OiANCj4gDQo+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzSExp dU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcNCj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNCg0K VGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxlLCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb3B5 IGhleCBkdW1wcyBvZiBib3RoIHJlcXVlc3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gSG93 YXJkIENodQ0KICBDVE8sIFN5bWFzIENvcnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNv bQ0KICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5 Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcv cHJvamVjdC8NCg==

1 0

Re: (ITS#8970) bind fails when length value is multi-byte
by hyc＠symas.com 03 Feb '19

03 Feb '19

lit(a)cbord.com wrote: > Full_Name: Leo Tohill > Version: 2.4.30 > OS: Windows 10 > URL: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… > Submission from: (NULL) (74.79.8.41) > > > Summary: openldap 2.4.30 does not accommodate multi-byte length value on bind > request. > > > First, I'll admit that I'm out of my depth here, I'm running a older version, > I'm on Windows, and my package was built by I don't know. But I worked hard > enough to track this down that I want you to know what I found. I might > upgrade, but that's problematic. > > At some point my bindings from .net began failing with "the username or password > is incorrect" But they were correct. I could confirm with various other tools. > I captured the wire traffic to isolate the problem. It turns out that Windows > forms the binding request using a multi-byte length indicator in the request. > OpenLdap apparently does not accommodate this. I compared to a request > generated by ldapsearch.exe. That request, which succeeds, varies only by > using a single-byte length indicator. > > The multi-byte length value should be allowed, right? Isn't it possible to have > a bind request data packet of length > 127? Which would require a multi-byte > length value. Perhaps this was fixed in a later version. > > Screenshots of the wire capture here: > > https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… This URL is inaccessible, permission denied. Just copy hex dumps of both requests here in text. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs