Description of problem: Replication breaks between 2 masters, one running 1.2.2 and one running 1.2.6.1. The 1.2.6.1 master fails trying to replicate to the 1.2.2 master. 1.2.6.1 server's relevant log messages: [14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Unable to parse the response to the startReplication extended operation. Replication is aborting. [14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Incremental update failed and requires administrator action 1.2.2 server's relevant log messages: [14/Oct/2010:16:26:19 -0400] conn=139 fd=65 slot=65 SSL connection from 130.207.183.16 to 130.207.183.14 [14/Oct/2010:16:26:19 -0400] conn=139 op=0 BIND dn="cn=Replication Manager,cn=config" method=128 version=3 [14/Oct/2010:16:26:19 -0400] conn=139 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config" [14/Oct/2010:16:26:19 -0400] conn=139 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [14/Oct/2010:16:26:19 -0400] conn=139 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [14/Oct/2010:16:26:19 -0400] conn=139 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [14/Oct/2010:16:26:19 -0400] conn=139 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [14/Oct/2010:16:26:19 -0400] conn=139 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [14/Oct/2010:16:26:19 -0400] conn=139 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [14/Oct/2010:16:26:19 -0400] conn=139 op=4 EXT oid="2.16.840.1.113730.3.5.12" [14/Oct/2010:16:26:19 -0400] conn=139 op=4 RESULT err=2 tag=120 nentries=0 etime=0 [14/Oct/2010:16:27:19 -0400] conn=139 op=5 UNBIND [14/Oct/2010:16:27:19 -0400] conn=139 op=5 fd=65 closed - U1 It looks like the 1.2.6.1 master is trying to make the 1.2.2 master use the 2.16.840.1.113730.3.5.12 extended operation and isn't happy when it gets refused. The rootdse of the 1.2.2 server is: dn: objectClass: top namingContexts: dc=gted,dc=gatech,dc=edu namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: LOGIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: GSSAPI supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.2 B2009.237.2054 dataversion: 020101015151757020101015151757020101015151757020101015151757 netscapemdsuffix: cn=ldap://dc=stefan,dc=iam,dc=gatech,dc=edu:389 Version-Release number of selected component (if applicable): 1.2.2 and 1.2.6.1 How reproducible: Random, sometimes it works, sometimes it doesn't. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: A quick grep through the code shows that repl90consumer (a field of Private_Repl_Protocol struct) is never initialized to zero. Neither is field repl71consumer. However field repl50consumer is initialized to zero in Repl_5_Inc_Protocol_new.
Created attachment 454163 [details] Patch
Pushed to master. Thanks to Rich for his review! Counting objects: 15, done. Delta compression using 2 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 880 bytes, done. Total 8 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git f39aab7..52632d7 master -> master
Steps to verify 1. install DS9.0 on hostA and DS8.2 on hostB. 2. set up mmr between the 2 servers. 3. run consumer initialization on DS9.0. run any mod op on DS9.0 and check that the mod is replicated to 8.2. run any mod op on DS8.2 and check that the mod is replicated to 9.0. 4. run consumer initialization on DS8.2. run any mod op on DS9.0 and check that the mod is replicated to 8.2. run any mod op on DS8.2 and check that the mod is replicated to 9.0.