[Openswan Users] multiple tunnel fails after upgrade, kernel 2.6.8 bug!?

[Vik Heyndrickx]

> -----Original Message-----
> From: Herbert Xu [mailto:herbert at gondor.apana.org.au]
> Sent: Tuesday, September 07, 2004 2:41 PM
> To: Vik Heyndrickx
> Cc: users at openswan.org; Ken Bantoft
> Subject: Re: [Openswan Users] multiple tunnel fails after upgrade,
> kernel 2.6.8 bug!?
> 
> 
> On Tue, Sep 07, 2004 at 10:26:35PM +1000, herbert wrote:
> > On Tue, Sep 07, 2004 at 02:00:54PM +0200, Vik Heyndrickx wrote:
> > > 
> > > I can from the left host:
> > > - never ping 10.222.222.1, regardless wether the tunnel 
> is up or not
> > > - ping 10.222.223.1, but only when the tunnel is up, as expected.
> > 
> > What if you ping with -s 10000, does it work then?
> 
> If it does, then this patch should fix the problem.

Just tested. It does.

> What happened is that I filled in the SA selectors before the policy
> selectors became fully functional.  However, SA selectors were only
> a temporary hack and broke with IPIP tunnel SAs which are used by
> IPCOMP.
> 
> What doesn't make sense is why it didn't work for you when you
> disabled compression.

I have clear recollection of turning compress on and off several times over the last few days since I discovered the problem, and tried to find out what was going on. It did not solve my problem. I just tried it once more, now in my test setup (before applying the patch ;-) ), and indeed there is no problem pinging when compression is disabled. I don't know what happened, why it worked now and not before. Maybe I made a mistake or could there maybe something else influencing this? The original gateway had a few more tunnels to different gateways...

[following imported from the next message]
> It means that when the packet passes through ipcomp it works,
> and when it passes through xfrm4_tunnel it breaks.
> The cause is a bug in openswan (my fault).

I'm happy that code exists (apart from that bug), otherwise openswan would probably not exist the way it exists now in the first place, so who's to blame...
So, Herbert et al, Thanks!

-- 
Vik