[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [SOLVED] slapd 2.3.11: protocol error, historical protocol version requested
Hello again,
Many thanks to you Buchan, and also to Hallvard.
Thanks to you, the following command revealed the whole thing:
[root@rhas root]# rpm -qf `which ldapsearch`
file /u01/app/oracle/product/817/bin/ldapsearch is not owned by any package
In fact, all my tests started the binaries located in my Oracle 8i
installation (except slapd)! I did not even knew ldap* was a content of the
Oracle DB package, so I'd never thought I was using the wrong binaries...
After some $PATH tweaks, and using the right binaries, ldapsearch, ldapadd,
etc work like a charm.
Answering Hallvard now: thanks for the tip, but slapd doesn't start with
that option enabled, I think because I did not compile
with --enable-slp=yes. But I'm thinking about recompiling...
So I consider this as solved. Thanks again.
Kevin
----- Original Message -----
From: "Buchan Milne" <bgmilne@staff.telkomsa.net>
To: "Kevin Roettger" <network@jeanrey.fr>
Cc: <openldap-software@OpenLDAP.org>
Sent: Monday, December 05, 2005 4:49 PM
Subject: Re: slapd 2.3.11: protocol error, historical protocol version
requested
On Monday 05 December 2005 13:28, Kevin Roettger wrote:
> Hello,
>
> First off, I'm really new to LDAP, so please be patient with me ;)
>
> I'm trying to make slapd work on my RedHat
More specific versions would be useful.
> , and after some compilation
> issues (mostly Berkeley DB library path issues), I finally managed to
build
> it. Here is the ./configure command used (I don't need SASL):
> ./configure --with-cyrus-sasl=no
>
> Make test succeeded without any errors.
And 'make install' ?
> I followed the installation and configuration manual, started slapd and
all
> that, but I'm stuck when testing the connection:
>
> [root@rhas openldap-2.3.11]# ldapsearch -b '' -s base '(objectclass=*)'
> namingContexts
> ldap_bind: Protocol error
> ldap_bind: additional info: historical protocol version requested, use
> LDAPv3 instead
Where does this ldapsearch come from?
rpm -qf `which ldapsearch`
may help ...
> (by the way, the following command:
> ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
> shown in the quickstart page doesn't work with -x, tells me the option
> doesn't exist)
-x works in all versions of OpenLDAP ldapsearch I have seen, but may not
necessarily work with other versions of ldapsearch (for instance Sun's,
maybe
also the one shipped in RH's ldapsdk package?).
The output of 'ldapsearch -VV' or similar may (or may not) be useful in
resolving where your ldapserach comes from, as would 'rpm -qf `which
ldapsearch`'
> And here is the log (level -1) from slapd when attempting the command:
>
> --------------------------------------------------------------------------
-
>-
>
> daemon: activity on 1 descriptors
> daemon: new connection on 12
> conn=0 fd=12 ACCEPT from IP=192.0.0.123:45951 (IP=0.0.0.0:389)
> daemon: added 12r
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: activity on: 12r
> daemon: read activity on 12
> connection_get(12)
> connection_get(12): got connid=0
> connection_read(12): checking for input on id=0
> ber_get_next
> ldap_read: want=8, got=8
> 0000: 30 0c 02 01 01 60 07 02 0....`..
> ldap_read: want=6, got=6
> 0000: 01 02 04 00 80 00 ......
> ber_get_next: tag 0x30 len 12 contents:
> ber_dump: buf=0x081c6618 ptr=0x081c6618 end=0x081c6624 len=12
> 0000: 02 01 01 60 07 02 01 02 04 00 80 00 ...`........
> ber_get_next
> ldap_read: want=8 error=Resource temporarily unavailable
> ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
> daemon: select: listen=6 active_threads=0 tvp=NULL
> do_bind
> ber_scanf fmt ({imt) ber:
> ber_dump: buf=0x081c6618 ptr=0x081c661b end=0x081c6624 len=9
> 0000: 60 07 02 01 02 04 00 80 00 `........
> ber_scanf fmt (m}) ber:
> ber_dump: buf=0x081c6618 ptr=0x081c6622 end=0x081c6624 len=2
> 0000: 00 00 ..
>
> >>> dnPrettyNormal: <>
>
> <<< dnPrettyNormal: <>, <>
> do_bind: version=2 dn="" method=128
> conn=0 op=0 BIND dn="" method=128
> send_ldap_result: conn=0 op=0 p=2
> send_ldap_result: err=2 matched="" text="historical protocol version
> requested, use LDAPv3 instead"
> send_ldap_response: msgid=1 tag=97 err=2
> ber_flush: 71 bytes to sd 12
> 0000: 30 45 02 01 01 61 40 0a 01 02 04 00 04 39 68 69
> 0E...a@......9hi 0010: 73 74 6f 72 69 63 61 6c 20 70 72 6f 74 6f 63 6f
> storical protoco 0020: 6c 20 76 65 72 73 69 6f 6e 20 72 65 71 75 65 73
> l version reques 0030: 74 65 64 2c 20 75 73 65 20 4c 44 41 50 76 33 20
> ted, use LDAPv3 0040: 69 6e 73 74 65 61 64
> instead daemon: activity on 1 descriptors
> daemon: activity on: 12r
> daemon: read activity on 12
> connection_get(12)
> ldap_write: want=71, written=71
> 0000: 30 45 02 01 01 61 40 0a 01 02 04 00 04 39 68 69
> 0E...a@......9hi 0010: 73 74 6f 72 69 63 61 6c 20 70 72 6f 74 6f 63 6f
> storical protoco 0020: 6c 20 76 65 72 73 69 6f 6e 20 72 65 71 75 65 73
> l version reques 0030: 74 65 64 2c 20 75 73 65 20 4c 44 41 50 76 33 20
> ted, use LDAPv3 0040: 69 6e 73 74 65 61 64
> instead connection_get(12): got connid=0
> connection_read(12): checking for input on id=0
> ber_get_next
> ldap_read: want=8, got=0
>
> ber_get_next on fd 12 failed errno=0 (Success)
> connection_read(12): input error=-2 id=0, closing.
> connection_closing: readying conn=0 sd=12 for close
> connection_close: deferring conn=0 sd=12
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: select: listen=6 active_threads=0 tvp=NULL
> conn=0 op=0 RESULT tag=97 err=2 text=historical protocol version
requested,
> use LDAPv3 instead
> connection_resched: attempting closing conn=0 sd=12
> connection_close: conn=0 sd=12
> daemon: removing 12
> conn=0 fd=12 closed (connection lost)
>
> --------------------------------------------------------------------------
-
>-
>
> So here stops the fun. All commands like ldapadd and ldapsearch return
this
> protocol error message, and the FAQ is not helpful in this case
> (http://www.openldap.org/faq/data/cache/693.html). Using -P 2 and -P 3
> output exactly the same result.
>
> Thanks for any clue.
Most likely, your ldapsearch/ldapadd don't come from your OpenLDAP
installation.
--
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)