[strongSwan-dev] destroy callback_job in strongswan

[Tobias Brunner]

Hi,

>> 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
> still 
> 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
> ignored.

So there is a single condition value for ALL SAs?  How/when is the value
changed?

> 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).

Regards,
Tobias