linux-ipsec: problems found so far

Here's a preliminary run-down on the problems we've seen/found so far in the Raleigh bakeoff... Note that my copy of this list goes to a machine that I can't reach from here, so my list access is send-only at the moment, and I won't see any on-list responses until I'm back...

Note also that this mail will be in what Hugh Daniel calls "whiny mode" -- since it's being sent from within the US, all I can do is complain, I can't discuss/recommend/decree specific solutions. (Also, I'm not going to explicitly comment on the fact that some of the things that need action probably should get it from *me*, once I'm back.)

This is in essentially random order.

We've had much grief with issues unrelated to the software, e.g. cabling, Linux PCMCIA support, etc. I won't go into those.

Although it has not yet been a problem, I see room for trouble in the fact that we do not currently document (in documentation!) exactly which versions of the IETF drafts our code corresponds to. This is potentially important information, both for testers wanting to know who they can interoperate with, and for deciding where updates are needed.

It is difficult for people to even start putting together test suites when our command-line interfaces keep changing.

The item labels in our part of the kernel-config menus need work.

New functional modes, e.g. transport mode, are quite useless unless accompanied by at least minimal documentation (even just an example in a README file) on how to set things up to use them.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

It would be nice if the kernel stuff didn't *have* to be a loadable module.

There needs to be a way to determine which version of the kernel code is present in the kernel you are running. And all programs, even daemons, should support a --version option.

It is disconcerting to discover that a program dumps core when invoked without arguments. Even when its legitimate use requires arguments, this still seems inappropriate.

Argument parsing in general seems rather fragile; we've seen some core dumps which may be due to assumptions about usage patterns. Error messages would be more helpful.

Debugging such problems is difficult when (experimental!) programs are compiled, by default, without debugging symbols.

We ran into some awkwardness when one of the makefiles used mv, rather than cp or install, in "make install".

More later...

                                                           Henry Spencer
                                                       henry@zoo.toronto.edu