Hi Martin, Thanks for your help. The problem is that we have a propritary implementaion of the IP stack in micro engine whose development is in assembly language.
As per what you have suggested, I think it would make sense that we let the kernel interface remain as is ( just change address family of the sockets with compatiple ones ) and let another process sniff these messages and provide an adpater interface with the network processor/micro engine. This adapter would then provide all required interfaces to the strongswan What are your thoughts on the same ? Regards, Vivek. On 7/2/09, Martin Willi <mar...@strongswan.org> wrote: > 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
