On 2/1/12 10:55 AM, masarati@aero.polimi.it wrote:

...

I have built and upgraded one of my openldap servers from 2.4.26 to 2.4.28 (on RHEL release 5.7 x86_64) and with the identical configuration to my other servers, I am seeing the following messages in the slapd.log file:

slapd[4434]: conn=115331 fd=263 ACCEPT from IP=X.X.X.X:51856 (IP=0.0.0.0:389) slapd[4434]: conn=115331 op=0 do_extended: protocol version (2) too low slapd[4434]: conn=115331 op=0 DISCONNECT tag=120 err=2 text=requires LDAPv3 slapd[4434]: conn=115331 fd=263 closed (operations error)

I'm not seeing anything leaping out at me from the change log for 2.4.27/2.4.28 that indicates what I have gotten wrong that worked until now.

As I said, I am running the same slapd.conf file on my 2.4.26 installations and not seeing these failures there at all (and since I use an F5 load balancer, these connections are sprayed all across my pool of servers).

Where should I start looking?

"do_extended" means an extended operation is being requested with protocol version set to LDAPv2, and LDAPv2 has no notion of extended operations. Can you track what operation is being requested?

With guidance about how to, I can certainly do my best to.

I can use tcpdump to gather all traffic between the client and this server on port 389 - but, I'm not going to be able to understand what I'm catching. Is there a more preferred method of capturing this?

p.

On 2/1/12 10:55 AM, masarati@aero.polimi.it wrote:

...

...

I have built and upgraded one of my openldap servers from 2.4.26 to 2.4.28 (on RHEL release 5.7 x86_64) and with the identical configuration to my other servers, I am seeing the following messages in the slapd.log file:

slapd[4434]: conn=115331 fd=263 ACCEPT from IP=X.X.X.X:51856 (IP=0.0.0.0:389) slapd[4434]: conn=115331 op=0 do_extended: protocol version (2) too low slapd[4434]: conn=115331 op=0 DISCONNECT tag=120 err=2 text=requires LDAPv3 slapd[4434]: conn=115331 fd=263 closed (operations error)

I'm not seeing anything leaping out at me from the change log for 2.4.27/2.4.28 that indicates what I have gotten wrong that worked until now.

As I said, I am running the same slapd.conf file on my 2.4.26 installations and not seeing these failures there at all (and since I use an F5 load balancer, these connections are sprayed all across my pool of servers).

Where should I start looking?

"do_extended" means an extended operation is being requested with protocol version set to LDAPv2, and LDAPv2 has no notion of extended operations. Can you track what operation is being requested?

With guidance about how to, I can certainly do my best to.

I can use tcpdump to gather all traffic between the client and this server on port 389 - but, I'm not going to be able to understand what I'm catching. Is there a more preferred method of capturing this?

Starting slapd with -d -1 would dump everything, including a tcp dump of the request. Of course you shouldn't do this in production. Moreover, you should isolate the logs from the beginning of the offending request to the point where the error message is returned, to avoid sending too large messages.

p.

On 2/1/12 12:56 PM, Francis Swasey wrote:

On 2/1/12 11:49 AM, Hallvard B Furuseth wrote:

...

On Wed, 01 Feb 2012 10:36:36 -0500, Francis Swasey Frank.Swasey@uvm.edu wrote:

...

slapd[4434]: conn=115331 op=0 do_extended: protocol version (2) too low (...) Where should I start looking?

At ITS#7107, which also had slapd thinking an LDAPv3 connection is v2. So, try the latest OPENLDAP_REL_ENG_2_4 from Git where it is fixed, or just commit 66943cad082eb0cbe19259b05a578bb318e511ad.

Ah! I'll try that first. It makes sense this is probably my problem.

I have rebuilt my openldap 2.4.28 with this patch applied and the server has been running for just over 14 hours now without another instance of the problem (which it had 202 times in under 3 hours with the stock 2.4.28).

Thanks for the pointer!