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

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