Re: nm-openswan development update

On Sun, 2007-03-25 at 20:05 -0400, steve wrote:
> Hi,
> It's been busy at work and hence development slows down accordingly, but 
> my weekends are free and I've made some big strides this weekend.
> I also wasted about 5 hours of my time today (not to mention the 
> frustration and head scratching for the past 3 weeks) at why the symbol 
> plugin for Anjuta (my IDE) wasn't working reliably: it sometimes 
> displayed correct data, then other times it wouldn't display that same 
> data at all.
> The 5 hours today went towards 3 efforts:
> 1. Try out eclipse (read the docs -- it doesn't support automake build 
> systems)
> 2. Try out Kdevelop (well.. I'm not developing for KDE and it crashed 
> everytime I tried to import my project or create a new GTK+ project and 
> import my source
> 3. Try to compile the latest source of the next rev of Anjuta: Too many 
> library version conflicts with my FC6 installation to make a sane build 
> enviornment feisable on my laptop.
> Then I stumbled across the reason for all my problems: I started with 
> the source to nm-vpnc (FC6 src rpm + redhat patches) and of course, just 
> like copying in school, you get the mistakes as well as the correct 
> answers.
> Moral of the Story: Don't copy verbatim if you can avoid it.
> After I fixed the problem ( which had to do with name/type conflicts on 
> typedef struct definitions ) the symbol browser in FC6's default 
> installation of Anjuta started working perfectly.
> Afterwards, I ran a build of the default vpc source (Just for kicks) 
> and  saw warnings about the same thing. Anyway, just wanted to save 
> people time if anyone else is writing a vpn plugin, and started with the 
> source an existing one for reference like I did.
> Development continues on nm-openswan and I hope to have a complete set 
> of working alpha code for all targets of the plugin in about 2 weeks. At 
> that point I'm going to setup some kind of CVS repository for the dist.
> There is still one big design question to be answered through testing. 
> If anyone knows openswan well, or cares to help me figure this one out, 
> feel free to offer advice. Here's my dilema:
> Call out to /usr/libexec/ipsec/whack to initiate/terminate an ipsec 
> connection

What's involved in the whack code to initiate/terminate the connection?
i.e. how complex is the code there?


> -OR-
> integrate the code for whack into my project and link against it at 
> build time (so my code actually talks directly to pluto through a 
> socket). I don't like this idea as my code becomes dependant on a 
> specific version of openswan (it's hard to explain the why of that). 
> Each new major rev of openswan will require an update to my source and a 
> recompile to work again and introducing depenancies doesn't seem to fit 
> with the design goals of NetworkManager.

Hopefully not; is the whack/pluto interface considered "internal" API to
the project?  If so, that's pretty dumb because apparently the only
public interface they offer is suboptimal CLI tools.  We do not want to
wrap CLI tools with GUI bits, we want the GUI gits to be capable of the
full functionality for a variety of reasons.


> All feedback welcome.
> I'll send another update once I've got this problem licked and the alpha 
> code compiles (without segfaults  at runtime ;)
> Steve.
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]