@rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf $(DIR_DL)/$(DL_FILE)
cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/strongswan-4.5.3_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
+