ipcomp regression in 2.6.24

ipcomp regression in 2.6.24

[Beschorner Daniel]

Has someone an idea which patch could have damaged ipcomp?

Daniel

> With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
> flows in both directions, but no data comes out of the tunnel.
> Needed to disable ipcomp.

Re: ipcomp regression in 2.6.24

[Marco Berizzi]

Beschorner Daniel wrote:

> Has someone an idea which patch could have damaged ipcomp?
>
> Daniel
>
> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
> > flows in both directions, but no data comes out of the tunnel.
> > Needed to disable ipcomp.

Same problem here: linux 2.6.24 driven by openswan 2.4.11
on Slackware 11.0

Re: ipcomp regression in 2.6.24

[Herbert Xu]

Marco Berizzi <pupilla@hotmail.com> wrote:
>
>> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
>> > flows in both directions, but no data comes out of the tunnel.
>> > Needed to disable ipcomp.
> 
> Same problem here: linux 2.6.24 driven by openswan 2.4.11
> on Slackware 11.0

My bad.  This patch should fix it.

[IPCOMP]: Fetch nexthdr before ipch is destroyed

When I moved the nexthdr setting out of IPComp I accidently moved
the reading of ipch->nexthdr after the decompression.  Unfortunately
this means that we'd be reading from a stale ipch pointer which
doesn't work very well.

This patch moves the reading up so that we get the correct nexthdr
value.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index f4af99a..b79cdbe 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -74,6 +74,7 @@ out:
 
 static int ipcomp_input(struct xfrm_state *x, struct sk_buff *skb)
 {
+	int nexthdr;
 	int err = -ENOMEM;
 	struct ip_comp_hdr *ipch;
 
@@ -84,13 +85,15 @@ static int ipcomp_input(struct xfrm_state *x, struct sk_buff *skb)
 
 	/* Remove ipcomp header and decompress original payload */
 	ipch = (void *)skb->data;
+	nexthdr = ipch->nexthdr;
+
 	skb->transport_header = skb->network_header + sizeof(*ipch);
 	__skb_pull(skb, sizeof(*ipch));
 	err = ipcomp_decompress(x, skb);
 	if (err)
 		goto out;
 
-	err = ipch->nexthdr;
+	err = nexthdr;
 
 out:
 	return err;
diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c
index b276d04..710325e 100644
--- a/net/ipv6/ipcomp6.c
+++ b/net/ipv6/ipcomp6.c
@@ -64,6 +64,7 @@ static LIST_HEAD(ipcomp6_tfms_list);
 
 static int ipcomp6_input(struct xfrm_state *x, struct sk_buff *skb)
 {
+	int nexthdr;
 	int err = -ENOMEM;
 	struct ip_comp_hdr *ipch;
 	int plen, dlen;
@@ -79,6 +80,8 @@ static int ipcomp6_input(struct xfrm_state *x, struct sk_buff *skb)
 
 	/* Remove ipcomp header and decompress original payload */
 	ipch = (void *)skb->data;
+	nexthdr = ipch->nexthdr;
+
 	skb->transport_header = skb->network_header + sizeof(*ipch);
 	__skb_pull(skb, sizeof(*ipch));
 
@@ -108,7 +111,7 @@ static int ipcomp6_input(struct xfrm_state *x, struct sk_buff *skb)
 	skb->truesize += dlen - plen;
 	__skb_put(skb, dlen - plen);
 	skb_copy_to_linear_data(skb, scratch, dlen);
-	err = ipch->nexthdr;
+	err = nexthdr;
 
 out_put_cpu:
 	put_cpu();

Re: ipcomp regression in 2.6.24

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 30 Jan 2008 14:15:33 +1100

> Marco Berizzi <pupilla@hotmail.com> wrote:
> >
> >> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
> >> > flows in both directions, but no data comes out of the tunnel.
> >> > Needed to disable ipcomp.
> > 
> > Same problem here: linux 2.6.24 driven by openswan 2.4.11
> > on Slackware 11.0
> 
> My bad.  This patch should fix it.
> 
> [IPCOMP]: Fetch nexthdr before ipch is destroyed
> 
> When I moved the nexthdr setting out of IPComp I accidently moved
> the reading of ipch->nexthdr after the decompression.  Unfortunately
> this means that we'd be reading from a stale ipch pointer which
> doesn't work very well.
> 
> This patch moves the reading up so that we get the correct nexthdr
> value.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, and queued for -stable, thanks!

Re: ipcomp regression in 2.6.24

[Marco Berizzi]

David Miller wrote:

> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed, 30 Jan 2008 14:15:33 +1100
>
> > Marco Berizzi <pupilla@hotmail.com> wrote:
> > >
> > >> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine,
data
> > >> > flows in both directions, but no data comes out of the tunnel.
> > >> > Needed to disable ipcomp.
> > >
> > > Same problem here: linux 2.6.24 driven by openswan 2.4.11
> > > on Slackware 11.0
> >
> > My bad.  This patch should fix it.
> >
> > [IPCOMP]: Fetch nexthdr before ipch is destroyed
> >
> > When I moved the nexthdr setting out of IPComp I accidently moved
> > the reading of ipch->nexthdr after the decompression.  Unfortunately
> > this means that we'd be reading from a stale ipch pointer which
> > doesn't work very well.
> >
> > This patch moves the reading up so that we get the correct nexthdr
> > value.
> >
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Applied, and queued for -stable, thanks!

Hi David,
I haven't seen this patch in Greg 2.6.24-stable
review message.

Re: ipcomp regression in 2.6.24

[David Miller]

From: "Marco Berizzi" <pupilla@hotmail.com>
Date: Fri, 8 Feb 2008 10:12:25 +0100

> I haven't seen this patch in Greg 2.6.24-stable
> review message.

Due to having just returned from LCA08 I haven't
made any -stable submissions in a while, and I
notified Greg of this tonight.

The networking fixes will make it into the next
2.6.24.x release.

Re: ipcomp regression in 2.6.24

[Marco Berizzi]

Herbert Xu wrote:

> Marco Berizzi <pupilla@hotmail.com> wrote:
> >
> >> > With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine,
data
> >> > flows in both directions, but no data comes out of the tunnel.
> >> > Needed to disable ipcomp.
> >
> > Same problem here: linux 2.6.24 driven by openswan 2.4.11
> > on Slackware 11.0
>
> My bad.  This patch should fix it.

Sorry for bother you again.
I have applied to 2.6.24, but ipcomp doesn't work anyway.
I have patched a clean 2.6.24 tree and I did a complete
rebuild.
With tcpdump I see both the esp packets going in/out but
I don't see the clear packets on the interface.

Re: ipcomp regression in 2.6.24

[Herbert Xu]

On Wed, Jan 30, 2008 at 10:14:46AM +0100, Marco Berizzi wrote:
>
> Sorry for bother you again.
> I have applied to 2.6.24, but ipcomp doesn't work anyway.
> I have patched a clean 2.6.24 tree and I did a complete
> rebuild.
> With tcpdump I see both the esp packets going in/out but
> I don't see the clear packets on the interface.

After testing it here it looks like there is this little typo
which means that you can't actually use IPComp for anything
that's not compressible :)

[IPCOMP]: Fix reception of incompressible packets

I made a silly typo by entering IPPROTO_IP (== 0) instead of
IPPROTO_IPIP (== 4).  This broke the reception of incompressible
packets.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/xfrm4_tunnel.c b/net/ipv4/xfrm4_tunnel.c
index 3268451..152f83d 100644
--- a/net/ipv4/xfrm4_tunnel.c
+++ b/net/ipv4/xfrm4_tunnel.c
@@ -50,7 +50,7 @@ static struct xfrm_type ipip_type = {
 
 static int xfrm_tunnel_rcv(struct sk_buff *skb)
 {
-	return xfrm4_rcv_spi(skb, IPPROTO_IP, ip_hdr(skb)->saddr);
+	return xfrm4_rcv_spi(skb, IPPROTO_IPIP, ip_hdr(skb)->saddr);
 }
 
 static int xfrm_tunnel_err(struct sk_buff *skb, u32 info)

Re: ipcomp regression in 2.6.24

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 31 Jan 2008 16:32:21 +1100

> [IPCOMP]: Fix reception of incompressible packets
> 
> I made a silly typo by entering IPPROTO_IP (== 0) instead of
> IPPROTO_IPIP (== 4).  This broke the reception of incompressible
> packets.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks!

Re: ipcomp regression in 2.6.24

[Marco Berizzi]

Herbert Xu wrote:

> On Wed, Jan 30, 2008 at 10:14:46AM +0100, Marco Berizzi wrote:
> >
> > Sorry for bother you again.
> > I have applied to 2.6.24, but ipcomp doesn't work anyway.
> > I have patched a clean 2.6.24 tree and I did a complete
> > rebuild.
> > With tcpdump I see both the esp packets going in/out but
> > I don't see the clear packets on the interface.
>
> After testing it here it looks like there is this little typo
> which means that you can't actually use IPComp for anything
> that's not compressible :)

applied and tested to 2.6.24: ipcomp is working now.
As always, thanks a lot Herbert for fixing this.

Re: ipcomp regression in 2.6.24

[Beschorner Daniel]

> applied and tested to 2.6.24: ipcomp is working now.
> As always, thanks a lot Herbert for fixing this.

Thank you too, I applied the 2 patches and it works.

Daniel