Acquire should be supported by both pfkey and netlink. However, it stops to send acquire message from the kernel on first success. It is possible that one or the other manager maybe passively monito
Yes that's a good catch. One problem though is that if theal real KM is dead but the passive monitor is still there then the kernel will have to wait for the larval states to time out. It can happen
Agreed. Well its useful even if we could just run "ip mon" to look at acquires going across. If i understood correctly pfkey: the kernel can be told when a KM is about to die or just came back up usi
I haven't checked af_key but netlink does support that. All you have to do is send messages to the correct multicast group. Of course whether any of the KMs actually deal with it is a different story
Herbert Xu wrote: On Fri, Mar 25, 2005 at 07:54:31PM -0500, jamal wrote: It seems that we dont support any acquires from userspace to kernel I haven't checked af_key but netlink does support that. Al
What i have seen being described is as follows: user space app --> kernel acquire with all necessary parameters kernel --> XFRMGRP_ACQURE acquire as it would right now with an outbound packet some KM
You're right. Neither xfrm_user/af_key is doing this at the moment. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://
You could say i am obssesed by this aquire message - I dont know why;-> I noticed in the absence of a responsive KM, the acquires are sent forever. Is it 30 seconds and may be degenerating to 60 seco
It's only sitting there forever because ping is configured to send packets forever by default. Try ping -c 1 and things will probably be different. Cheers, -- Visit Openswan at http://www.openswan.or
Actually it won't. It will try it forever when the larval state expires. When we fix the xfrm state resolution, we can add a knob for this case. Cheers, -- Visit Openswan at http://www.openswan.org/
Herbert/Dave, Acquire should be supported by both pfkey and netlink. However, it stops to send acquire message from the kernel on first success. It is possible that one or the other manager maybe pas
Yes that's a good catch. One problem though is that if theal real KM is dead but the passive monitor is still there then the kernel will have to wait for the larval states to time out. It can happen
Agreed. Well its useful even if we could just run "ip mon" to look at acquires going across. If i understood correctly pfkey: the kernel can be told when a KM is about to die or just came back up usi
I haven't checked af_key but netlink does support that. All you have to do is send messages to the correct multicast group. Of course whether any of the KMs actually deal with it is a different story
It seems that we dont support any acquires from userspace to kernel I haven't checked af_key but netlink does support that. All you have to do is send messages to the correct multicast group. Of cou
What i have seen being described is as follows: user space app --> kernel acquire with all necessary parameters kernel --> XFRMGRP_ACQURE acquire as it would right now with an outbound packet some KM
You're right. Neither xfrm_user/af_key is doing this at the moment. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://
You could say i am obssesed by this aquire message - I dont know why;-> I noticed in the absence of a responsive KM, the acquires are sent forever. Is it 30 seconds and may be degenerating to 60 seco
It's only sitting there forever because ping is configured to send packets forever by default. Try ping -c 1 and things will probably be different. Cheers, -- Visit Openswan at http://www.openswan.or