openldap-bugs May 2009

openldap-bugs@openldap.org

42 participants
159 discussions

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 10 May '09

10 May '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 3909 says both the Cancel operation and the canceled operation > shall respond. However I'm getting tooLate reply from Cancel > and no response from the successfully cancelled operation: The tooLate reply is correct; back-null doesn't ever check for cancel/abandon therefore the operation is *not* successfully canceled. Likewise, back-bdb/hdb only checks in Delete if there is a transaction retry. The lack of reply from the original op - that's a simple oversight. send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I guess we need to also check for o_cancel to let it proceed. > > slapd.conf: > include servers/slapd/schema/core.schema > database null > suffix "cn=null" > client: > DEL cn=null > sleep 0.1 sec > CANCEL<previous op> > sleep 0.2 sec > UNBIND > receives the folllowing statslog: > conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) > conn=1 op=0 DEL dn="cn=null" > conn=1 op=1 EXT oid=1.3.6.1.1.8 > conn=1 op=1 CANCEL msg=1 > conn=1 op=0 ABANDONED > conn=1 op=1 RESULT oid= err=120 text= > conn=1 op=2 UNBIND > conn=1 fd=9 closed > and the client gets just ExtendedResponse tooLate before connection closes > > with the following patch to slapd: > > Index: delete.c > --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 > +++ delete.c 9 May 2009 22:06:07 -0000 > @@ -75,4 +75,9 @@ > op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); > > + { > + struct timeval timeout = { 0, 200000 }; > + select(0, NULL, NULL, NULL,&timeout); > + } > + > if( op->o_req_ndn.bv_len == 0 ) { > Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", > Index: result.c > --- result.c 14 Mar 2009 05:47:43 -0000 1.329 > +++ result.c 9 May 2009 22:06:07 -0000 > @@ -418,4 +418,6 @@ > if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { > rc = SLAPD_ABANDON; > + Statslog( LDAP_DEBUG_STATS, > + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); > goto clean2; > } > > > -- -- 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#6102) configure skips winsock check
by hyc＠symas.com 10 May '09

10 May '09

slapd(a)hannebauer.name wrote: > Full_Name: Christoph Hannebauer > Version: 2.4.16 > OS: Windows/cygwin > URL: www.hannebauer.name/configure.in.patch > Submission from: (NULL) (77.189.243.40) > > > I use cygwin to build OpenLDAP with the MinGW target. The configure script > incorrectly skips the check for winsock. This results in a missing -lws2_32 > parameter in some makefiles, I get error messages like > > /cygdrive/d/TestProgs/openldap-2.4.16/libraries/liblber/io.c:531: undefined > reference to `_WSASetLastError@4' > > The author of ITS#6078 (http://www.openldap.org/its/index.cgi/Incoming?id=6078) > notes that this problem occurs since 2.4.14, but I haven't tested that. Thanks. Yes, the configure script handling of winsock changed between 2.4.13 and 2.4.14. This patch is now committed to HEAD. > > The attached patch file is a diff to configure.in version 1.696. I have tested > it on my machine and it solved the problem (The reason was an erroneous > if-statement. The if-condition should only evaluate true if MS Visual C++ is > used). I've also included another small fix for the winsock detection which > happened to not affect my system, but seemed obviously wrong. It's only a very > minor fix, so I assumed it would be okay to not open another ticket for that > patch. If I am wrong, please notify me and I will split up the patch file. > > I hope it's okay to have the legal statement here, otherwise I will include it > as a comment in the patch file: > I, Christoph Hannebauer, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > -- -- 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#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 09 May '09

09 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 3909 says both the Cancel operation and the canceled operation shall respond. However I'm getting tooLate reply from Cancel and no response from the successfully cancelled operation: slapd.conf: include servers/slapd/schema/core.schema database null suffix "cn=null" client: DEL cn=null sleep 0.1 sec CANCEL <previous op> sleep 0.2 sec UNBIND receives the folllowing statslog: conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) conn=1 op=0 DEL dn="cn=null" conn=1 op=1 EXT oid=1.3.6.1.1.8 conn=1 op=1 CANCEL msg=1 conn=1 op=0 ABANDONED conn=1 op=1 RESULT oid= err=120 text= conn=1 op=2 UNBIND conn=1 fd=9 closed and the client gets just ExtendedResponse tooLate before connection closes with the following patch to slapd: Index: delete.c --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 +++ delete.c 9 May 2009 22:06:07 -0000 @@ -75,4 +75,9 @@ op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); + { + struct timeval timeout = { 0, 200000 }; + select(0, NULL, NULL, NULL, &timeout); + } + if( op->o_req_ndn.bv_len == 0 ) { Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", Index: result.c --- result.c 14 Mar 2009 05:47:43 -0000 1.329 +++ result.c 9 May 2009 22:06:07 -0000 @@ -418,4 +418,6 @@ if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { rc = SLAPD_ABANDON; + Statslog( LDAP_DEBUG_STATS, + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); goto clean2; }

1 0

(ITS#6102) configure skips winsock check
by slapd＠hannebauer.name 09 May '09

09 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: www.hannebauer.name/configure.in.patch Submission from: (NULL) (77.189.243.40) I use cygwin to build OpenLDAP with the MinGW target. The configure script incorrectly skips the check for winsock. This results in a missing -lws2_32 parameter in some makefiles, I get error messages like /cygdrive/d/TestProgs/openldap-2.4.16/libraries/liblber/io.c:531: undefined reference to `_WSASetLastError@4' The author of ITS#6078 (http://www.openldap.org/its/index.cgi/Incoming?id=6078) notes that this problem occurs since 2.4.14, but I haven't tested that. The attached patch file is a diff to configure.in version 1.696. I have tested it on my machine and it solved the problem (The reason was an erroneous if-statement. The if-condition should only evaluate true if MS Visual C++ is used). I've also included another small fix for the winsock detection which happened to not affect my system, but seemed obviously wrong. It's only a very minor fix, so I assumed it would be okay to not open another ticket for that patch. If I am wrong, please notify me and I will split up the patch file. I hope it's okay to have the legal statement here, otherwise I will include it as a comment in the patch file: I, Christoph Hannebauer, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 09 May '09

09 May '09

hyc(a)symas.com ha scritto: > > It certainly looks that way. What version is the provider, what version is the > consumer? You only said there were mixed versions before, you never specified > which was which. > Both are same version: 2.4.16 + patches (looking at RELENG I simply anticipated Quanah in merging from HEAD). Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by hyc＠symas.com 09 May '09

09 May '09

masarati(a)aero.polimi.it wrote: > luca.scamoni(a)sys-net.it wrote: >> hyc(a)symas.com ha scritto: >>> Good idea. >>> >>> Also, I think the original LDAP message should still be intact, in frame 6 >>> "msg" - perhaps you can extract the DN that was actually received and figure >>> out why it had a problem. >>> >> This is the msg from frame 6 >> >> (gdb) p msg->lm_ber->ber_buf[0]@100 >> $4 = >> "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" > > The second '\000' after '\004' (octet string) was probably put by > ber_scanf("m") to terminate the string, but the first one seems to be > the length of the octet string! So apparently the message actually > contained an empty DN, which makes little sense. Could the error be at > the provider's side? It certainly looks that way. What version is the provider, what version is the consumer? You only said there were mixed versions before, you never specified which was which. -- -- 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#6099) SIGSEGV heimdal+ldap during kadmin -l init
by hyc＠symas.com 09 May '09

09 May '09

dewayne_freebsd(a)yahoo.com wrote: > Full_Name: Dewayne Geraghty > Version: 2.4.16 > OS: FreeBSD-7.2R > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.172.112.108) > > > Fresh build of OS, ports from heimdal, openldap-2.4.16, cyrus-sasl-2.1.22_2, > ltdl-1.5.26. What does "ports from heimdal" mean? What version of Heimdal are you using? I've built Heimdal 1.2.1 and it works fine. > During kadmin -l init --realm-max-ticket-life=unlimited > --realm-max-renewable-life=unlimited HS2 > a segmentation fault is raised. > > gdb /usr/local/sbin/kadmin > run -l init --realm-max-ticket-life=unlimited > --realm-max-renewable-life=unlimited HS2 > #0 0x285693c6 in memmove () from /lib/libc.so.7 > #1 0x28235c0d in ber_write (ber=0x2860b340, buf=0x51<Error reading address > 0x51: Bad address>, len=81, nosos=0) > at io.c:116 > #2 0x28234525 in ber_put_ostring (ber=0x2860b340, str=0x51<Error reading > address 0x51: Bad address>, len=81, > tag=4) at encode.c:357 This trace indicates that incorrect parameters were provided to the ldap_add function(s). In particular, the attrs passed in are using char * values, but the flags were set to indicate that struct bervals were being passed. As such, this is a bug in whatever version of Heimdal you used. There is no OpenLDAP issue here, this ITS will be closed. Furthermore, it appears that there is no bug in current Heimdal versions either. > #3 0x28234625 in ber_put_berval (ber=0x2860b340, bv=0x2860711c, tag=4294967295) > at encode.c:382 > #4 0x28235729 in ber_printf (ber=0x2860b340, fmt=0x281c99de "V]N}") at > encode.c:838 > #5 0x2819a074 in ldap_add_ext (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420, > sctrls=0x0, cctrls=0x0, msgidp=0xbfbfe6bc) at add.c:170 > #6 0x2819a2b0 in ldap_add_ext_s (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420, > sctrls=0x0, cctrls=0x0) at add.c:229 > #7 0x2819a36b in ldap_add_s (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420) > at add.c:243 > #8 0x280b028f in LDAP_store (context=0x286010b0, db=0x2860a040, flags=0, > entry=0xbfbfe770) at hdb-ldap.c:1580 > #9 0x2809a8f0 in kadm5_s_create_principal (server_handle=0x2861a0c0, > princ=0xbfbfea1c, mask=17, > password=0xbfbfe810 "Vbc2zAiigq") at create_s.c:182 > #10 0x2808eac9 in kadm5_create_principal (server_handle=0x2861a0c0, > princ=0xbfbfea1c, mask=17, > password=0xbfbfe810 "Vbc2zAiigq") at common_glue.c:64 > and > (gdb) x 0x2860711c > 0x2860711c: 0x00000051 > > This is reproducable with/without overlays (except for smbk5pwd overlay); built > and tested afresh on two machines, using make -pipe -O0 -g3 > > Note to build smbk5passwd on FreeBSD, needed to change smbk5pwd Makefile: > #HEIMDAL_INC=-I/usr/heimdal/include > HEIMDAL_INC=-I/usr/local/include > #HEIMDAL_LIB=-L/usr/heimdal/lib -lkrb5 -lkadm5srv > HEIMDAL_LIB=-L/usr/local/lib -lkrb5 -lkadm5srv > > The ldap database is built using one group entry (ou=Users,dc=..). Have used > ldap for 3 years, kerberos for 4 months. -- -- 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#6101) Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 08 May '09

08 May '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The sru_search and sru_extended components of SlapReply.sr_un are commonly used uninitialized. When a union is initialized, only the first union member (sru_sasl) is initialized. Compilers may but need not fill the rest with something. One partial fix would be to make sru_search the first union element, That's the most commonly used member and also the biggest, so initializing it is likely to help for other cases as well. Whether or not we do that, in connection.c:connection_operation(), the switch ( tag ) can initialize the uninitialized members, all but one of LDAP_REQ_BIND, LDAP_REQ_SEARCH, and/or LDAP_REQ_EXTENDED. We need to check grep -nH -e 'SlapReply[<tab> ]*[a-zA-Z]' *.c */*.c for other cases.

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by masarati＠aero.polimi.it 08 May '09

08 May '09

luca.scamoni(a)sys-net.it wrote: > hyc(a)symas.com ha scritto: >> Good idea. >> >> Also, I think the original LDAP message should still be intact, in frame 6 >> "msg" - perhaps you can extract the DN that was actually received and figure >> out why it had a problem. >> > This is the msg from frame 6 > > (gdb) p msg->lm_ber->ber_buf[0]@100 > $4 = > "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" The second '\000' after '\004' (octet string) was probably put by ber_scanf("m") to terminate the string, but the first one seems to be the length of the octet string! So apparently the message actually contained an empty DN, which makes little sense. Could the error be at the provider's side? p. > (gdb) p msg->lm_ber->ber_buf[100]@100 > $5 = > "Point\004\003top0\r\004\002cn\000\a\004\005CRL190&\004\fcreatorsName\000\026\004\024cn=directory > manager0$\004\017createTimestamp\000\021\004\017200603131301" > (gdb) p msg->lm_ber->ber_buf[200]@100 > $6 = > "20Z0/\004\025structuralObjectClass\000\026\004\024cRLDistributionPoint0\202\002X\004 > certificateRevocationList;binary\000\202\0022\004\202\002.0\202" > (gdb) p msg->lm_ber->ber_buf[300]@100 > $7 = > "\002*0\202\001\022\002\001\0010\r\006\t*\206H\206Ã·\r\001\001\005\005\0000\201\2101\v0\t\006\003U\004\006\023\002IT1\0270\025\006\003U\004\n\023\016Actalis > S.p.A.1\"0 \006\003U\004\v\023\031Servizi di certificazion" > (gdb) p msg->lm_ber->ber_buf[400]@100 > $8 = "e1<0:\006\003U\004\003\0233Regione Siciliana Certification > Authority Cittadini\027\r090507070003Z\027\r090508070003Z0\"0 \002\001\025" > (gdb) p msg->lm_ber->ber_buf[500]@100 > $9 = > "\027\r060330073258Z0\f0\n\006\003U\035\025\004\003\n\001\001 10/0\f\006\003U\035\024\004\005\002\003\002\031(0\037\006\003U\035#\004\0300\026\200\024ÂŸ\232Ã¡\027'ÃŒ\214Â»\004)i > ,x\"Â©<\226\210E0\r\006\t*\206H\206Ã·\r\001\001\005\005\000\003\202\001\001" > (gdb) p msg->lm_ber->ber_buf[600]@100 > $10 = > "E6Â¥Â©Ã\023t\"Ãa\235ZÂ€Â²@(Ã(\222ÃGÃ©'R!\234\\Â€\027ÂªzÃ~lÂ¹z\032Ã»ÃÂ©ÃªqÃ\202::cÂ³Ã¡Ã#\n2Â±ÃÃš+AÂ¯ÃÂŽÂ¥Â¶#ÃŒ^Â¡\003Ã\030\235`Âš\032\027Â±ÃÃvÃ¹OÃ\230Â¶\233Ã£\004K\201&\\r]Ã\233DÃ>]R" > (gdb) p msg->lm_ber->ber_buf[700]@100 > $11 = > "4\213\t\a>X^Ã\224Ãž]Ã¥\034#eÃQ\215Ã®ÃºÃzbÂ¯ÃšfÃPCÂ«\202Ã£Â¯Z\177\024Â¯ÂŒ%ÃÃÂ¶8\022ÃÂ¯<\234Â»ZÃk\213Âµ\bÂŒQÃšÃQ\205\232ÃÂ¥\n3\212v\noÃ¥e+U\034Ã\212\207\215\231+\2374Â«ÃªÃNÂ€Â¡\222\000Â±hÃYÂž+ÃŽ8-" > (gdb) p msg->lm_ber->ber_buf[800]@100 > $12 = > "Ã Â¯\234\214Ã¬8ÃŽa\177IÂ§ÂškÂ€\001N\217~,Â°>Â£\217\1771ÃÃ³ÂœxÃ\206Ã\214ÃO5Ã%5Â»:Ã\206ÃÃ¡\235Ã°?\nÃ²VÃ¡Ã£W\"\21606\004\bentryCSN\000*\004(20090507070014.234380Z#00000" > (gdb) p msg->lm_ber->ber_buf[900]@100 > $13 = > "0#000#00000005\004\rmodifiersName\000$\004\"cn=manager,dc=a,dc=prod,dc=actalis0$\004\017modifyTimestamp\000\021\004\0172009050707" > (gdb) p msg->lm_ber->ber_buf[1000]@100 > $14 = > "0014Z0\r\004\aentryDN\000\002\004\0000#\004\021subschemaSubentry\000\016\004\fcn=Subschema0\032\004\017hasSubordinates\000\a\004\005FALSE k0i\004\0301.3.6.1.4" > (gdb) p msg->lm_ber->ber_buf[1100]@100 > $15 = > ".1.4203.1.9.1.2\004M0K\n\001\002\004\020j\vÂ¡\026Â²\221\021Ã\200\006\207Ã¶ÃŠyÃ±Âœ\0044rid=002,csn=20090507070014.234380Z#000000#000#000000\0000%\000\000" > > I fear the dn is already lost... :-( > > > Ing. Luca Scamoni > Responsabile Ricerca e Sviluppo > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 0382 573859 (137) > Fax: +39 0382 476497 > Email: luca.scamoni(a)sys-net.it > ----------------------------------- > > >

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 08 May '09

08 May '09

hyc(a)symas.com ha scritto: > > Good idea. > > Also, I think the original LDAP message should still be intact, in frame 6 > "msg" - perhaps you can extract the DN that was actually received and figure > out why it had a problem. > This is the msg from frame 6 (gdb) p msg->lm_ber->ber_buf[0]@100 $4 = "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" (gdb) p msg->lm_ber->ber_buf[100]@100 $5 = "Point\004\003top0\r\004\002cn\000\a\004\005CRL190&\004\fcreatorsName\000\026\004\024cn=directory manager0$\004\017createTimestamp\000\021\004\017200603131301" (gdb) p msg->lm_ber->ber_buf[200]@100 $6 = "20Z0/\004\025structuralObjectClass\000\026\004\024cRLDistributionPoint0\202\002X\004 certificateRevocationList;binary\000\202\0022\004\202\002.0\202" (gdb) p msg->lm_ber->ber_buf[300]@100 $7 = "\002*0\202\001\022\002\001\0010\r\006\t*\206H\206÷\r\001\001\005\005\0000\201\2101\v0\t\006\003U\004\006\023\002IT1\0270\025\006\003U\004\n\023\016Actalis S.p.A.1\"0 \006\003U\004\v\023\031Servizi di certificazion" (gdb) p msg->lm_ber->ber_buf[400]@100 $8 = "e1<0:\006\003U\004\003\0233Regione Siciliana Certification Authority Cittadini\027\r090507070003Z\027\r090508070003Z0\"0 \002\001\025" (gdb) p msg->lm_ber->ber_buf[500]@100 $9 = "\027\r060330073258Z0\f0\n\006\003U\035\025\004\003\n\001\001 10/0\f\006\003U\035\024\004\005\002\003\002\031(0\037\006\003U\035#\004\0300\026\200\024¾\232á\027'ü\214»\004)i ,x\"©<\226\210E0\r\006\t*\206H\206÷\r\001\001\005\005\000\003\202\001\001" (gdb) p msg->lm_ber->ber_buf[600]@100 $10 = "E6¥©×\023t\"ía\235Z¤²@(É(\222ÆGé'R!\234\\¤\027ªzÄ~l¹z\032ûÕ©êqÃ\202::c³áÈ#\n2±Âè+A¯Ö´¥¶#ü^¡\003Í\030\235`¨\032\027±ÍßvùOØ\230¶\233ã\004K\201&\\r]É\233DÏ>]R" (gdb) p msg->lm_ber->ber_buf[700]@100 $11 = "4\213\t\a>X^Ê\224ø]å\034#eÂQ\215îú×zb¯èfíPC«\202ã¯Z\177\024¯¼%ÓÎ¶8\022Í¯<\234»ZÍk\213µ\b¼Qè×Q\205\232Û¥\n3\212v\noåe+U\034Å\212\207\215\231+\2374«êÖN¤¡\222\000±hËY¸+ô8-" (gdb) p msg->lm_ber->ber_buf[800]@100 $12 = "à¯\234\214ì8ôa\177I§¨k¤\001N\217~,°>£\217\1771Èó½xÛ\206Ù\214íO5Ì%5»:Á\206Âá\235ð?\nòVáãW\"\21606\004\bentryCSN\000*\004(20090507070014.234380Z#00000" (gdb) p msg->lm_ber->ber_buf[900]@100 $13 = "0#000#00000005\004\rmodifiersName\000$\004\"cn=manager,dc=a,dc=prod,dc=actalis0$\004\017modifyTimestamp\000\021\004\0172009050707" (gdb) p msg->lm_ber->ber_buf[1000]@100 $14 = "0014Z0\r\004\aentryDN\000\002\004\0000#\004\021subschemaSubentry\000\016\004\fcn=Subschema0\032\004\017hasSubordinates\000\a\004\005FALSE k0i\004\0301.3.6.1.4" (gdb) p msg->lm_ber->ber_buf[1100]@100 $15 = ".1.4203.1.9.1.2\004M0K\n\001\002\004\020j\v¡\026²\221\021Ú\200\006\207öæyñ½\0044rid=002,csn=20090507070014.234380Z#000000#000#000000\0000%\000\000" I fear the dn is already lost... :-( Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2009