strongswan: Update to 5.1.2dr3.

src/patches/strongswan-5.1.1-delay-dpd.patch

@@ -1,35 +0,0 @@
-From b76e96e2ef4d56c863b36c8d3c39e3c2efcf4a7c Mon Sep 17 00:00:00 2001
-From: Martin Willi <martin@revosec.ch>
-Date: Fri, 1 Nov 2013 11:28:53 +0100
-Subject: [PATCH] ike: Don't immediately DPD after deferred DELETEs following IKE_SA rekeying
-
-Some peers seem to defer DELETEs a few seconds after rekeying the IKE_SA, which
-is perfectly valid. For short(er) DPD delays, this leads to the situation where
-we send a DPD request during set_state(), but the IKE_SA has no hosts set yet.
-Avoid that DPD by resetting the INBOUND timestamp during set_state().
----
- src/libcharon/sa/ike_sa.c |    8 ++++++++
- 1 files changed, 8 insertions(+), 0 deletions(-)
-
-diff --git a/src/libcharon/sa/ike_sa.c b/src/libcharon/sa/ike_sa.c
-index 0282087..d482f8b 100644
---- a/src/libcharon/sa/ike_sa.c
-+++ b/src/libcharon/sa/ike_sa.c
-@@ -687,6 +687,14 @@ METHOD(ike_sa_t, set_state, void,
- 					DBG1(DBG_IKE, "maximum IKE_SA lifetime %ds", t);
- 				}
- 				trigger_dpd = this->peer_cfg->get_dpd(this->peer_cfg);
-+				if (trigger_dpd)
-+				{
-+					/* Some peers delay the DELETE after rekeying an IKE_SA.
-+					 * If this delay is longer than our DPD delay, we would
-+					 * send a DPD request here. The IKE_SA is not ready to do
-+					 * so yet, so prevent that. */
-+					this->stats[STAT_INBOUND] = this->stats[STAT_ESTABLISHED];
-+				}
- 			}
- 			break;
- 		}
--- 
-1.7.4.1
-