include Config
-VER = 5.1.1
+VER = 5.1.2dr3
THISAPP = strongswan-$(VER)
DL_FILE = $(THISAPP).tar.bz2
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = e3af3d493d22286be3cd794533a8966a
+$(DL_FILE)_MD5 = 0a2aba6b0682cc01eb4f9bbeb94bc481
install : $(TARGET)
@$(PREBUILD)
@rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf $(DIR_DL)/$(DL_FILE)
cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/strongswan-5.0.2_ipfire.patch
- cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/strongswan-5.1.1-delay-dpd.patch
cd $(DIR_APP) && [ -x "configure" ] || ./autogen.sh
cd $(DIR_APP) && ./configure \
+++ /dev/null
-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
-