Hi, > 1. Could you please throw some light on how is the updated IP list is > given to the stack
The roam job just indicates the network configuration has changed. While processing the job, a route lookup is done to find a new (or keep the existing) path to reach the peer. > 2. We saw that the XFRM_Expire message is received from the kernel. > Is it then the correct assumptions that strongswan does not maintain > the re-keying timer for the child SAs? Yes, IKE_SA lifetimes are handled in the daemon, while CHILD_SA lifetimes are handled in the kernel. The reason for this is that there are (theoretically) other ways to expire an SA, only known to the kernel (e.g. number of bytes/packets processed). > 3. Could you let us know the best approach for plugging out the kernel > interface and using our own? Removing the kernel interface is probably the most complex option, you would need to work around a lot of functionality in the core daemon. The right way to do it is implement a kernel interface for IPsec and networking for the QNX system. QNX uses a PF_KEY interface [1], so you could try to use our existing PF_KEY plugin. As NetBSD uses a policy handling concept similar to KLIPS (flows), you probably need to borrow some bits from the KLIPS plugin. For the networking part, QNX uses the PF_ROUTE protocol [2] from BSD. You could try to use our PF_ROUTE plugin. It should work, but might not be feature complete. If you are willing to sponsor the development, you could hand over your QNX porting efforts to us. The strongSwan team has some experience in porting to BSD based systems... Regards Martin [1]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ipsec_proto.html [2]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/r/route_proto.html _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
