[strongSwan-dev] destroy callback_job in strongswan

[Baal Su]

Hi Tobias, 

	Thank you for your patient explanation. 

> On 16 Sep 2015, at 14:14, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> 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.
> 

As far as I know, this busy waiting is the only solution I can use in the plugin. The 
plugin is used to send http requests in a high frequency, such as 15 seconds
per request. And I would like not to bond the http request frequency to the 
re-key/authentication frequency, since we could change the key or re-authenticate 
each other in every hour.

>>> 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?

This value is the returned result of the http request. As I said above, this http
request is sent very frequently, so we cannot predict when to close the ipsec
connection.

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

I found the solution with a pointer, what I need is not complex, I just 
need to pass the active IKE unique id into the callback job. With a pointer
I manage to do so. 

Sorry my question is a little bit stupid.

Thank you very much and best wishes!
Tao

> 
> Regards,
> Tobias
>