ikev2: (Re-)Queue tasks used to establish an IKE_SA in reset()

Some tasks might get removed immediately once the IKE_SA_INIT response has
been handled even if there were notifies that require a restart of the
IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD).  Such a task is ike_vendor,
which caused vendor IDs not to get sent in a retry.  This change ensures
all required tasks are queued after the reset, which some callers did
already anyway.
This commit is contained in:
Tobias Brunner 2016-08-24 11:34:36 +02:00
parent fd1662cdbd
commit d9fe0ec712
1 changed files with 1 additions and 2 deletions

View File

@ -921,6 +921,7 @@ METHOD(ike_sa_t, reset, void,
this->ike_sa_id->is_initiator(this->ike_sa_id));
this->task_manager->reset(this->task_manager, 0, 0);
this->task_manager->queue_ike(this->task_manager);
}
METHOD(ike_sa_t, get_keymat, keymat_t*,
@ -1831,7 +1832,6 @@ METHOD(ike_sa_t, reauth, status_t,
DBG0(DBG_IKE, "reinitiating IKE_SA %s[%d]",
get_name(this), this->unique_id);
reset(this);
this->task_manager->queue_ike(this->task_manager);
return this->task_manager->initiate(this->task_manager);
}
/* we can't reauthenticate as responder when we use EAP or virtual IPs.
@ -2335,7 +2335,6 @@ METHOD(ike_sa_t, retransmit, status_t,
this->keyingtry + 1, tries);
reset(this);
resolve_hosts(this);
this->task_manager->queue_ike(this->task_manager);
return this->task_manager->initiate(this->task_manager);
}
DBG1(DBG_IKE, "establishing IKE_SA failed, peer not responding");