Thread: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users
|
From: Ramon S. <RSc...@gm...> - 2008-07-17 13:08:54
|
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. According to the info in KConfig,
KLIPS_ALG should only be disabled when OCF is used - which setting
is right?
My guess is: KLIPS_ALG is necessary, but it results in Error when
used together with KLIPS_OCF set (see ipsec_xmit.c).
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).
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);
- }
+
Greetings, Ramon
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
|
|
From: David M. <Dav...@se...> - 2008-07-17 23:29:46
|
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.
> 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 ;-)
> 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 ?
> 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).
>
> 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 ;-)
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
|
From: David M. <Dav...@se...> - 2008-07-18 14:42:00
Attachments:
alg.patch
|
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
|
|
From: Ramon S. <RSc...@gm...> - 2008-07-18 15:09:12
|
Hi David & List,
> > > > 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.
>
it was causing me the problem that "ipsec eroute --clear" didnt work
anymore. It seems to me that calling SENDERR(-0) was just an quick and
dirty - though working - trick to finish the "clear"-Request.
Cheers & thanks for your support,
Ramon
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
|
|
From: David M. <Dav...@se...> - 2008-07-18 15:54:26
|
Jivin "Ramon Schönborn" lays it down ...
> Hi David & List,
> > > > > 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.
>
> it was causing me the problem that "ipsec eroute --clear" didnt work
> anymore. It seems to me that calling SENDERR(-0) was just an quick and
> dirty - though working - trick to finish the "clear"-Request.
Its definately possible, but it didn't look right. I imagine I changed it
during the big ocf-merge because it didn't look right.
If it is causing you problems then I say back out the change ;-)
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X