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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
