Hi Martin, Thanks for your comments.
I have been able to write a plugin to manage the control and listener aspects of Charon but see that adding configuration support would require significant effort. In fact the Stroke socket API would provide all that I need aside from the listener feedback, do you see this ever becoming a public API at some point in the future? Regards, Ian. On 5 Mar 2010, at 08:24, Martin Willi wrote: > Hi, > >> 1.) Use the normal config files and invoke the ipsec script (no way of >> getting indications?). > > This is one option, but probably the worst. The protocol between ipsec > and the daemon is designed for command line invocation, not to write an > API. Parsing the status output is pain, and it probably will break with > every release. > > I won't recommend this approach, unless you want support for IKEv1 > setups via pluto. > >> 2.) Write a Charon plugin (like the NM plugin, I quite like this approach). > > Thats the clean solution and very flexible. You can provide the > mechanisms exactly as you need them. While we have different plugins you > can have a look at, this will require some time to get in touch with > daemon internals and APIs. > >> 3.) Use DBUS and the NM plugin (I have no idea about DBUS). > > The NM DBUS API is far from ideal, as it is designed for NM, and not for > strongSwan. It is very limited to the specific needs of NM initiated > connections. > > We have more generic plugins, such as the SMP plugin. SMP is an XML > based plugin for control and configuration functions via a Unix socket. > It is not feature-complete and we haven't put much work in it during the > last years. It is usable, but probably would require some daemon-side > work. > > Configuration-wise, we also have sql based plugins. These are very > generic and render the schemas relatively complex. But it might be a > good (if not too complicated) example how to integrate your own > configuration backend. > >> 4.) Re-use the Stroke API (probably not a good idea). > > No, stroke has been designed to work with ipsec.conf configurations, and > not with IKEv2 specific concepts. Further, all you get back via this > interface is ASCII, exactly as in 1.). > > > Assuming you go for 2.): > >> 1.) Programatically configure StrongSwan (Charon). > > You would have to instanciate connection objects, ike_cfg_t, peer_cfg_t, > child_cfg_t. To provide connections as responder, serve these configs > via backend_t. To initiate connections, pass them to the controller_t. > >> 2.) Be able to up/down connections. > > The simplest way to control the daemon is through the controller_t > helper class. > >> 3.) Get indications when connections go down (e.g. through DPD). > > Implement the listener_t interface (or some methods of it) and register > it to the bus_t. > >> What are the GPL implications of writing a plugin, I assume it would >> also become GPL? > > Yes, if you distribute binaries, you'll have to provide your plugin > code, too. Contact Andreas if you're interested in alternative licensing > schemes. > > Regards > Martin > _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
