[Openswan dev] ocf debian

Paul Wouters paul at xelerance.com
Mon Dec 20 04:23:48 EST 2010

On Mon, 20 Dec 2010, Harald Jenny wrote:

>> Yes it does. Though at this moment, since OCF is not standard in the kernel (and prob
>> never will be because of the alternative but less developed "acrypto"), the user
>> has explicitely decided to want ocf. So it makes sense.
> Not userfriendly and may really piss off admins. I as an admin may decide to
> install OCF on a machine for later testing (at my decision) but the next time I
> restart openswan they get loaded anyway (which may result in undesired
> behavior).

The same situation would occur using a new config setup option "ocf", which would
have the default value of "use when available". So I'm not sure how the admin would
be less "pissed off".

>> You said "loads cryptodev", that is a side effect.
> Sorry what I meant was: run internal "ipsec --versioncode" - when we detect
> pluto was compiled with OCF support then load cryptodev (I'm personally not a
> fan of modifying ipsec scripts as they will be overwritten when the next
> version gets installed.

We could change _startklips when compiling with OCF support for userland and load the
cryptodev module. And not do so without OCF support. I'll add that for the next

>> _startklips already does that now, except for the specific hardware modules. I'm not
>> sure if it would make sense to try all the hardware that hardly anyone would have.
>> Though I'm willing to do something that looks into "lspci" and loads whatever it
>> finds. But then someone needs to tell me the pci identifiers for these hardware
>> cards, since I don't have many of them.
> Hmmm sorry from the git log entry I thought you always try to load cryptoloop
> regardless if KLIPS is compiled with it or OCF is installed.

We only probe for cryptosoft in _startklips, meaning you have set protostack=klips|mast.
This is done regardless of compile time options for userland/klips. Since KLIPS now does
support checking this value via /sys/module/ipsec/parameters/ocf_available we could
skip trying the modprobe for cryptosoft, but I'm not sure if this is worth the extra
code. Also, it would not solve the reverse problem. If the admin has manually loaded
cryptosoft, should we unload the module to avoid klips using it without the "ocf" config
option and possibly break other software using cryptosoft?

In the end, the current situations is pretty easy and most common - Try using kernel OCF
if available. I do agree we can load cryptodev if userland OCF support was enabled, and
will add that.


More information about the Dev mailing list