[strongSwan-dev] destroy callback_job in strongswan
tobias at strongswan.org
Wed Sep 16 14:14:58 CEST 2015
>> During a reauthentication the authorize() callback should be called
>> again for the new IKE_SA, so you could theoretically schedule a new job
>> for the new IKE_SA then.
> Yes, I set a flag in the plugin so this callback job is created only in
> the first
> authentication phase. But if I schedule a new job, the previous job is
> running, and as I mentioned, it is running in an infinite loop, so it
> will not
> be stopped.
Then add proper synchronization between the different jobs/threads (or
simply terminate the thread, e.g. by setting the condition value to -1,
and start a new job during reauthentication). But this busy waiting
doesn't sound ideal anyway.
>> But if you are actually referring to rekeying
>> then you might have to implement the ike_rekey() callback to keep track
>> of the IKE_SA_ID of the SA, which probably requires you to organize your
>> plugin differently. For instance, only have a single job that regularly
>> goes through a collection of SAs to check, which you then can update so
>> only the currently active SAs are contained in that collection. Or
>> structure the data passed to the job in a way that allows the
>> ike_rekey()-listener to update the IKE_SA_ID used by the job when it
>> runs later on.
> This is exactly how the plugin is organised. In the first authentication
> phase between
> the client and the server, the callback job is created and it keeps
> running in the
> background, and if the condition value changes, it will close the ipsec
> connection as
> I mentioned before. In the re-authentication phase, the callback job is
So there is a single condition value for ALL SAs? How/when is the value
> May I ask how to get this collection of SAs? I tried to use enumerator
> in the callback
> job before the condition value check, then the compile fails.
Just use an appropriate collection from libstrongswan/collections to
store the IDs. If you only track a single SA just pass a pointer to the
member that stores the ID to the callback job and update that ID as
needed (with appropriate synchronization).
More information about the Dev