Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel
Brought to you by:
david-m
Menu
▾
▴
Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel
|
From: David M. <Dav...@se...> - 2008-07-18 14:42:00
|
Jivin "Ramon Schönborn" lays it down ...
> > > Hello OCF-Linux-Users,
> > >
> > > i'm trying to run the latest OCF 20080704 Release together with
> > > linux-2.6.21.6 Kernel + Openswan 2.6.15dr2 on an IXP4XX Architecture.
> > >
> > > I have a Question concerning Config Options:
> > > - In the OCF Package, in File linux/net/ipsec/defconfig and
> > > packaging/linux/Config-all.h, CONFIG_KLIPS_OCF is not set while
> > > CONFIG_KLIPS_ALG is set to y.
> >
> > This is the default for non-ocf builds.
>
> okay, that did confuse me a bit because:
> - i didnt found any hint to tweak this config files
> - i didnt expect this behaviour for a patch. If i dont want a patch to
> do something, i wouldnt apply it ...
Well it's no longer a patch, it's part of openswan proper, and by
default the openswan guys don't want OCF enabled since it requires a
kernel patch.
Still, it's just house keeping really.
> > > According to the info in KConfig,
> > > KLIPS_ALG should only be disabled when OCF is used - which setting
> > > is right?
> >
> > I thought that read "may" only be disabled when using OCF, but perhaps
> > that fix got lost ;-)
>
> okay, that was just c&p from my mind ;-)
No probs.
> > > My guess is: KLIPS_ALG is necessary, but it results in Error when
> > > used together with KLIPS_OCF set (see ipsec_xmit.c).
> >
> > If you are going to use OCF and you want to reduce the size of your
> > kernel then you turn on CONFIG_KLIPS_OCF and turn off CONFIG_KLIPS_ALG.
> > You can then disable all the crypto options in openswan IIRC, you can
> > also disable most of the cryptoapi drivers.
> >
> > The reason you can do this is that OCF is effectively a full replacement
> > for the ALG code. And if you have a HW driver, you do not need the SW
> > crypto either.
> >
> > Does that make any sense ?
> I think so.
> What i meant with "see ipsec_xmit.c": about line 1568 (2.6.16dr4) we have a
> line of code: ixs->ixt_e=ixs->ipsp->ips_alg_enc;
> The Problem with this line occurs, when both KLIPS_ALG and KLIPS_OCF are
> defined - then this line becomes the "else"-branch of the if-command in the
> previous OCF-dependend block of code. The following if (ixs->ixt_e) { ...
> will be executed afterwards, though this will result in an error
> (IPSEC_XMIT_ESP_BADALG) later.
Yep, missed that thanks. patch attached.
> > > Mysteriously, my IPSec tunnel is established with:
> > > "IPsecConn-0" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
> > mode {ESP=>0x5f6f06b7 <0x785d1973 xfrm=AES_128-HMAC_MD5 NATOA=none
> > NATD=none DPD=none}"
> > > , and incomming Packets can be decrypted. Outgoing Packets instead
> > result in increasing TX Error Counter
> > > and a BADALG Error Message (if both, KLIPS_ALG and KLIPS_OCF are set).
> > >
>
> like i just tried to explain: that was the reason why i expexted KLIPS_ALG and
> KLIPS_OCF to be mutual exclusive.
They are supposed to work together so if they don't we have bugs to fix.
I must admit, I probably didn't do much more than bring the tunnels up
when I was testing. I will try and revisit soon.
> Unfortunately, when i have only KLIPS_OCF
> defined, the behaviour is nearly the same (tunnel established, encrypting
> fails) but i dont get an error message.
> Do you have any idea why this happens? The only useful debugging output i
> have is:
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: entering with encalg=12, ixt_e=bf1ec080
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=12 ips_key_e=c250e400 idat=c2c7824c ilen=96 iv=c2c7823c, encrypt=1
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: returned ret=96
> ...
> (some klips_dmp output)
> ...
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_findroute: 192.168.0.254:0->192.168.0.253:0 50
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: * See if we match exactly as a host destination
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ** try to match a leaf, t=0pc3680620
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: *** start searching up the tree, t=0pc3680620
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: **** t=0pc3680638
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: **** t=0pc2d64d60
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ***** cp2=0pc3016148 cp3=0pc2d65830
> Mar 1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ***** not found.
> (then nothing happens)
Seems like some problem with the tunnel addressing/association.
> Please not that the following bug is independent of the Problem decribed above:
ok.
> > > I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
> > > old 2.4.8 Version with the current one, a pair of curly braces changed
> > > the semantic.
> > > >From Line 2126 it should be like:
> > > - if ((error = ipsec_cleareroutes())) {
> > > + if ((error = ipsec_cleareroutes()))
> > > KLIPS_PRINT(debug_pfkey,
> > > "klips_debug:pfkey_x_delflow_parse:
> > "
> > > "cleareroutes returned %d.\n",
> > error);
> > > SENDERR(-error);
> > > - }
> > > +
> >
> > That is definately a problem but it looks like we already found it :-)
> > My code has the fix so I am guessing you need to try 2.6.16dr4, which
> > is what I have running here. It has settled down now but there was a "dr"
> > release every day there for a bit ;-)
>
> isnt fixed in 2.6.16dr4 yet. I forgot to mention that i'm already testing
> 2.6.16dr4 too.
Ok, I misread what you were saying and I see the code change.
Is this change causing you a problem ? IMO is looks like it was always
a bug as the code hasn't detected any errors yet does a jump to errlab
by calling SENDERR(-0).
I'll copy Paul Wouters at Xelerance to see what his thoughts are.
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
