[strongSwan-dev] destroy callback_job in strongswan
baaltommysu at gmail.com
Thu Sep 17 18:45:29 CEST 2015
Thank you for your patient explanation.
> On 16 Sep 2015, at 14:14, Tobias Brunner <tobias at strongswan.org> wrote:
>>> 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.
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
> So there is a single condition value for ALL SAs? How/when is the value
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
>> 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!
More information about the Dev