From 92c4c2a685d14be600518c8c3bda2a289d0188f7 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz <tbordaz@redhat.com>
Date: Mar 23 2018 15:12:25 +0000
Subject: Ticket 49619 - adjustment of csn_generator can fail so next generated csn can be equal to the most recent one received


Bug Description:
	On consumer side csn_generator ajustment occurs (let CSN = highest known csn)

	    when a replication session starts
	    when a csn is generated locally and than csn is <= CSN

	During adjustment, in the case

	    there is no remote/local offset (time change)
	    the current_time on the consumer is identical to CSN

	Then next locally generated csn will only differ with seqnum

	The seqnum of the csn_generator is increased only if CSN.seqnum is larger
	than the csn_generator one.
	In case of egality, it remains unchanged.

	The consequence is that the next locally generated csn will be identical to CSN (except for the RID).
	So even after csn_generator adjustment, csn_generator may create csn that are not larger than the CSN

Fix Description:
	compare the new generated timestamp (time+offsets) with adjustment one.
	If the new is greater or EQUAL, make sure the local seqnum is ahead the remote one

https://pagure.io/389-ds-base/issue/49619

Reviewed by: Mark Reynolds

Platforms tested: F27

Flag Day: no

Doc impact: no

---

diff --git a/ldap/servers/slapd/csngen.c b/ldap/servers/slapd/csngen.c
index 468979a..2c75c6d 100644
--- a/ldap/servers/slapd/csngen.c
+++ b/ldap/servers/slapd/csngen.c
@@ -368,7 +368,7 @@ int csngen_adjust_time(CSNGen *gen, const CSN* csn)
 		/* let's revisit the seq num - if the new time is > the old
 		   tiem, we should reset the seq number to remote + 1 if
 		   this won't cause a wrap around */
-		if (new_time > cur_time) {
+		if (new_time >= cur_time) {
 			/* just set seq_num regardless of whether the current one
 			   is < or > than the remote one - the goal of this function
 			   is to make sure we generate CSNs > the remote CSN - if