On 01.06.20 19:27, Noel Kuntze wrote: > Hello Micahel, > > xfrm_acq_expires is the time the kernel holds an acquire event before it > drops it. > The kernel only sends one acquire event for a policy, not several ones. When > it receives packets with a matching policy but without a corresponding IPsec > SA, > it checks if it already sent an acquire event. If an acquire event was not > reacted to within $xfrm_acq_expires seconds, that acquire event is forgotten > about by the kernel. > So basically xfrm_acq_expires is the minimum time between two acquire events > for a policy. > > Kind regards > > Noel
Thanks for the explanation. > > Am 29.05.20 um 15:41 schrieb Michael Schwartzkopff: >> Hi, >> >> what would be the effect if the charon.plugins.xfrm_acq_expires does not >> fit the charon.retransmit_* options? >> >> I tried to understand what the xfrm_acq_expires exactrly does, but the >> docs in the internet are very limited. As far as I understood, it sets a >> timer when the SPI times out. Every time, traffic is seens for a SPI, >> the timer is reset (?) >> >> If the total retransmit timeout is larger than the xfrm_acq_expired, >> could it happen that the SPI timed out before charon times out and the >> encrypted communication breaks? >> >> Or is there any good timing diagram for encrytped traffic though the kernel? >> >> >> Mit freundlichen Grüßen, >> Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
signature.asc
Description: OpenPGP digital signature
