IPv6 state match - possible bug.

IPv6 state match - possible bug.

[Ben Skeggs]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Hello,

I'm not sure if this is a bug, or something I'm doing incorrectly.

With the (attached) ruleset, I am able to receive ICMPv6 echo replies
correctly but any other type of connection fails.  The SYN+ACK reply
appears to get dropped by netfilter.

IP6-IN: IN=eth0 OUT= MAC=00:0f:ea:70:eb:f9:00:50:8d:e3:b5:89:86:dd
SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
FLOWLBL=1295 PROTO=TCP SPT=80 DPT=33215 WINDOW=57344 RES=0x00 ACK SYN
URGP=0

The above is from trying to "wget -6 www.kame.net".

araqiel ~ # gzcat /proc/config.gz | grep -E "NF_CO|STATE"
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CONNTRACK_MARK is not set
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NF_CONNTRACK_IPV4=y
# CONFIG_IP_NF_CONNTRACK is not set
CONFIG_NF_CONNTRACK_IPV6=y

Does the above config seem okay?

Thanks in advance,
Ben Skeggs.

[-- Attachment #2: Type: text/plain, Size: 1959 bytes --]

Chain INPUT (policy DROP 821 packets, 66160 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   44  3648 ACCEPT     all      lo     any     anywhere             anywhere           
 195K   70M allow-in   all      any    any     anywhere             anywhere           
  850 68504 LOG        all      any    any     anywhere             anywhere           limit: avg 10/min burst 5 LOG level warning prefix `IP6-IN: ' 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all      any    any     anywhere             anywhere           limit: avg 10/min burst 5 LOG level warning prefix `IP6-FW: ' 

Chain OUTPUT (policy DROP 20 packets, 5116 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   44  3648 ACCEPT     all      any    lo      anywhere             anywhere           
 181K   20M allow-out  all      any    any     anywhere             anywhere           
    0     0 LOG        all      any    any     anywhere             anywhere           limit: avg 10/min burst 5 LOG level warning prefix `IP6-OU: ' 

Chain allow-fwd (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain allow-in (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 190K   70M ACCEPT     all      eth0   any     2001:388:c17d::/64   anywhere           
   37  3992 ACCEPT     all      any    any     anywhere             anywhere           state RELATED,ESTABLISHED 
 3804  295K ACCEPT     all      any    any     fe80::/10            anywhere           

Chain allow-out (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 181K   20M ACCEPT     all      any    any     anywhere             anywhere           

Re: IPv6 state match - possible bug.

[Yasuyuki KOZAKAI]

From: Ben Skeggs <darktama@iinet.net.au>
Date: Mon, 13 Feb 2006 23:54:38 +1100

> Hello,
> 
> I'm not sure if this is a bug, or something I'm doing incorrectly.
> 
> With the (attached) ruleset, I am able to receive ICMPv6 echo replies
> correctly but any other type of connection fails.  The SYN+ACK reply
> appears to get dropped by netfilter.
> 
> IP6-IN: IN=eth0 OUT= MAC=00:0f:ea:70:eb:f9:00:50:8d:e3:b5:89:86:dd
> SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> FLOWLBL=1295 PROTO=TCP SPT=80 DPT=33215 WINDOW=57344 RES=0x00 ACK SYN
> URGP=0
> 
> The above is from trying to "wget -6 www.kame.net".
> 
> araqiel ~ # gzcat /proc/config.gz | grep -E "NF_CO|STATE"
> CONFIG_NF_CONNTRACK=y
> # CONFIG_NF_CONNTRACK_MARK is not set
> CONFIG_NF_CONNTRACK_EVENTS=y
> CONFIG_NF_CONNTRACK_FTP=y
> CONFIG_NETFILTER_XT_MATCH_STATE=y
> CONFIG_NF_CONNTRACK_IPV4=y
> # CONFIG_IP_NF_CONNTRACK is not set
> CONFIG_NF_CONNTRACK_IPV6=y
> 
> Does the above config seem okay?

looks fine to me. I tested with recent kernel, same kernrel config,
and same rules, but couldn't reproduce above log.

Which version of kernel(or git commit id) and ip6tables ?
And could you do
	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

and test same rule ?

Regards,

-- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Yasuyuki KOZAKAI]

From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Date: Tue, 14 Feb 2006 13:03:15 +0900 (JST)

> looks fine to me. I tested with recent kernel, same kernrel config,
> and same rules, but couldn't reproduce above log.
> 
> Which version of kernel(or git commit id) and ip6tables ?
> And could you do
> 	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

Sorry, right sysctl is

  	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid

-- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Ben Skeggs]

On Tue, 2006-02-14 at 13:16 +0900, Yasuyuki KOZAKAI wrote:
> From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> Date: Tue, 14 Feb 2006 13:03:15 +0900 (JST)
> 
> > looks fine to me. I tested with recent kernel, same kernrel config,
> > and same rules, but couldn't reproduce above log.
> > 
> > Which version of kernel(or git commit id) and ip6tables ?
> > And could you do
> > 	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
> 
> Sorry, right sysctl is
> 
>   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
Okay, seems there is an issue somewhere..  I'm using 2.6.16-rc3, and
also had the same issue with -rc2.  iptables is version 1.3.5.

nf_ct_tcp: bad TCP checksum IN= OUT=
SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 SEQ=1589838125 ACK=2289866071
WINDOW=57344 RES=0x00 ACK SYN URGP=0 OPT
(020405A0010303000101080A2DA73166049359BE)
IP6-IN: IN=eth0 OUT= MAC=00:0f:ea:70:eb:f9:00:50:8d:e3:b5:89:86:dd
SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 WINDOW=57344 RES=0x00 ACK SYN
URGP=0

Which is odd, without any ip6tables rules everything seems to work well.

Thanks,
Ben Skeggs.
> 
> -- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Ben Skeggs]

On Tue, 2006-02-14 at 13:16 +0900, Yasuyuki KOZAKAI wrote:
> From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> Date: Tue, 14 Feb 2006 13:03:15 +0900 (JST)
> 
> > looks fine to me. I tested with recent kernel, same kernrel config,
> > and same rules, but couldn't reproduce above log.
> > 
> > Which version of kernel(or git commit id) and ip6tables ?
> > And could you do
> > 	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
> 
> Sorry, right sysctl is
> 
>   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
Just another followup with some more info.. I built 2.6.16-rc3 on my
other machine (x86) and it does indeed appear to work correctly there.

I'm wondering if there is some amd64-specific bug?

Cheers,
Ben.
> 
> -- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Yasuyuki KOZAKAI]

From: Ben Skeggs <darktama@iinet.net.au>
Date: Tue, 14 Feb 2006 15:24:31 +1100

> On Tue, 2006-02-14 at 13:16 +0900, Yasuyuki KOZAKAI wrote:
> > From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> > Date: Tue, 14 Feb 2006 13:03:15 +0900 (JST)
> > 
> > > looks fine to me. I tested with recent kernel, same kernrel config,
> > > and same rules, but couldn't reproduce above log.
> > > 
> > > Which version of kernel(or git commit id) and ip6tables ?
> > > And could you do
> > > 	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
> > 
> > Sorry, right sysctl is
> > 
> >   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
> Okay, seems there is an issue somewhere..  I'm using 2.6.16-rc3, and
> also had the same issue with -rc2.  iptables is version 1.3.5.
> 
> nf_ct_tcp: bad TCP checksum IN= OUT=
> SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 SEQ=1589838125 ACK=2289866071
> WINDOW=57344 RES=0x00 ACK SYN URGP=0 OPT
> (020405A0010303000101080A2DA73166049359BE)

checksumming with your eth0 driver might be broken.
I'm not sure why, but I saw some reports about checksum for a few weeks.

> IP6-IN: IN=eth0 OUT= MAC=00:0f:ea:70:eb:f9:00:50:8d:e3:b5:89:86:dd
> SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 WINDOW=57344 RES=0x00 ACK SYN
> URGP=0
> 
> Which is odd, without any ip6tables rules everything seems to work well.

From: Ben Skeggs <darktama@iinet.net.au>
Date: Tue, 14 Feb 2006 16:53:01 +1100

> Just another followup with some more info.. I built 2.6.16-rc3 on my
> other machine (x86) and it does indeed appear to work correctly there.
> 
> I'm wondering if there is some amd64-specific bug?

Or they have different ether card, maybe. I'm using e100 and it works fine.

-- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Yasuyuki KOZAKAI]

[-- Attachment #1: Type: Text/Plain, Size: 1294 bytes --]


Hi, Ben,

From: Ben Skeggs <darktama@iinet.net.au>
Date: Wed, 15 Feb 2006 12:11:47 +1100

> > > > Sorry, right sysctl is
> > > > 
> > > >   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
> > > Okay, seems there is an issue somewhere..  I'm using 2.6.16-rc3, and
> > > also had the same issue with -rc2.  iptables is version 1.3.5.
> > > 
> > > nf_ct_tcp: bad TCP checksum IN= OUT=
> > > SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> > > DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> > > FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 SEQ=1589838125 ACK=2289866071
> > > WINDOW=57344 RES=0x00 ACK SYN URGP=0 OPT
> > > (020405A0010303000101080A2DA73166049359BE)
> > 
> > checksumming with your eth0 driver might be broken.
> > I'm not sure why, but I saw some reports about checksum for a few weeks.
> Thank you!  This was indeed the problem.

Finally I got time to check codes for this and found bug.
If you have some time, could you try attached patch ?
I tested with sky2, but it's great if I can confirm that it works fine
with other device.

> I swapped from my onboard Yukon (skge driver), to the nvidia card
> (forcedeth driver) and everything seems to work correctly now.
> 
> Sorry for the noise!

No. Thanks a lot for this report.

-- Yasuyuki Kozakai

[-- Attachment #2: nfct_checksum.patch --]
[-- Type: Text/Plain, Size: 2053 bytes --]

[NETFILTER] nf_conntrack: Fix TCP/UDP checksum handling for IPv6 packet

If skb->ip_summed is CHECKSUM_HW here, skb->csum includes checksum
of actual IPv6 header and extension headers. Then such excess
checksum must be subtruct when nf_conntrack calculates TCP/UDP checksum
with psuedo IPv6 header.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

---
commit 7f5523d7f49865e62b683b0519408cf15a5b5624
tree e79868f93168aadd3e07e96605c351009019197f
parent 5552c28f6937d2a2b873d06c6d09b96204722dd0
author <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900
committer <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900

 net/netfilter/nf_conntrack_proto_tcp.c |    4 +++-
 net/netfilter/nf_conntrack_proto_udp.c |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -864,7 +864,9 @@ static int csum6(const struct sk_buff *s
 {
 	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
 			       skb->len - dataoff, IPPROTO_TCP,
-			       skb->ip_summed == CHECKSUM_HW ? skb->csum
+			       skb->ip_summed == CHECKSUM_HW
+			       ? csum_sub(skb->csum,
+					  skb_checksum(skb, 0, dataoff, 0))
 			       : skb_checksum(skb, dataoff, skb->len - dataoff,
 					      0));
 }
diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
--- a/net/netfilter/nf_conntrack_proto_udp.c
+++ b/net/netfilter/nf_conntrack_proto_udp.c
@@ -161,7 +161,9 @@ static int csum6(const struct sk_buff *s
 {
 	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
 			       skb->len - dataoff, IPPROTO_UDP,
-			       skb->ip_summed == CHECKSUM_HW ? skb->csum
+			       skb->ip_summed == CHECKSUM_HW
+			       ? csum_sub(skb->csum,
+					  skb_checksum(skb, 0, dataoff, 0))
 			       : skb_checksum(skb, dataoff, skb->len - dataoff,
 					      0));
 }

Re: IPv6 state match - possible bug.

[Ben Skeggs]

On Tue, 2006-02-14 at 15:47 +0900, Yasuyuki KOZAKAI wrote:
> From: Ben Skeggs <darktama@iinet.net.au>
> Date: Tue, 14 Feb 2006 15:24:31 +1100
> 
> > On Tue, 2006-02-14 at 13:16 +0900, Yasuyuki KOZAKAI wrote:
> > > From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> > > Date: Tue, 14 Feb 2006 13:03:15 +0900 (JST)
> > > 
> > > > looks fine to me. I tested with recent kernel, same kernrel config,
> > > > and same rules, but couldn't reproduce above log.
> > > > 
> > > > Which version of kernel(or git commit id) and ip6tables ?
> > > > And could you do
> > > > 	echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
> > > 
> > > Sorry, right sysctl is
> > > 
> > >   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
> > Okay, seems there is an issue somewhere..  I'm using 2.6.16-rc3, and
> > also had the same issue with -rc2.  iptables is version 1.3.5.
> > 
> > nf_ct_tcp: bad TCP checksum IN= OUT=
> > SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> > DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> > FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 SEQ=1589838125 ACK=2289866071
> > WINDOW=57344 RES=0x00 ACK SYN URGP=0 OPT
> > (020405A0010303000101080A2DA73166049359BE)
> 
> checksumming with your eth0 driver might be broken.
> I'm not sure why, but I saw some reports about checksum for a few weeks.
Thank you!  This was indeed the problem.

I swapped from my onboard Yukon (skge driver), to the nvidia card
(forcedeth driver) and everything seems to work correctly now.

Sorry for the noise!

Ben Skeggs.
> 
> > IP6-IN: IN=eth0 OUT= MAC=00:0f:ea:70:eb:f9:00:50:8d:e3:b5:89:86:dd
> > SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> > DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> > FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 WINDOW=57344 RES=0x00 ACK SYN
> > URGP=0
> > 
> > Which is odd, without any ip6tables rules everything seems to work well.
> 
> From: Ben Skeggs <darktama@iinet.net.au>
> Date: Tue, 14 Feb 2006 16:53:01 +1100
> 
> > Just another followup with some more info.. I built 2.6.16-rc3 on my
> > other machine (x86) and it does indeed appear to work correctly there.
> > 
> > I'm wondering if there is some amd64-specific bug?
> 
> Or they have different ether card, maybe. I'm using e100 and it works fine.
> 
> -- Yasuyuki Kozakai

Re: IPv6 state match - possible bug.

[Ben Skeggs]

On Wed, 2006-02-15 at 03:43 +0900, Yasuyuki KOZAKAI wrote:
> Hi, Ben,
> 
> From: Ben Skeggs <darktama@iinet.net.au>
> Date: Wed, 15 Feb 2006 12:11:47 +1100
> 
> > > > > Sorry, right sysctl is
> > > > > 
> > > > >   	echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
> > > > Okay, seems there is an issue somewhere..  I'm using 2.6.16-rc3, and
> > > > also had the same issue with -rc2.  iptables is version 1.3.5.
> > > > 
> > > > nf_ct_tcp: bad TCP checksum IN= OUT=
> > > > SRC=2001:0200:0000:8002:0203:47ff:fea5:3085
> > > > DST=2001:0388:c17d:0000:020f:eaff:fe70:ebf9 LEN=80 TC=0 HOPLIMIT=56
> > > > FLOWLBL=525788 PROTO=TCP SPT=80 DPT=52498 SEQ=1589838125 ACK=2289866071
> > > > WINDOW=57344 RES=0x00 ACK SYN URGP=0 OPT
> > > > (020405A0010303000101080A2DA73166049359BE)
> > > 
> > > checksumming with your eth0 driver might be broken.
> > > I'm not sure why, but I saw some reports about checksum for a few weeks.
> > Thank you!  This was indeed the problem.
> 
> Finally I got time to check codes for this and found bug.
> If you have some time, could you try attached patch ?
> I tested with sky2, but it's great if I can confirm that it works fine
> with other device.
I applied your patch to 2.6.16-rc3, and swapped back to the skge chip, I
seem to have working IPv6 state matching now.  I set
nf_conntrack_log_invalid again, and have not seen any invalid packet
messages on dmesg at all.

Thanks for checking this out for me!

Ben Skeggs.
> 
> > I swapped from my onboard Yukon (skge driver), to the nvidia card
> > (forcedeth driver) and everything seems to work correctly now.
> > 
> > Sorry for the noise!
> 
> No. Thanks a lot for this report.
> 
> -- Yasuyuki Kozakai
> plain text document attachment (nfct_checksum.patch)
> [NETFILTER] nf_conntrack: Fix TCP/UDP checksum handling for IPv6 packet
> 
> If skb->ip_summed is CHECKSUM_HW here, skb->csum includes checksum
> of actual IPv6 header and extension headers. Then such excess
> checksum must be subtruct when nf_conntrack calculates TCP/UDP checksum
> with psuedo IPv6 header.
> 
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
> 
> ---
> commit 7f5523d7f49865e62b683b0519408cf15a5b5624
> tree e79868f93168aadd3e07e96605c351009019197f
> parent 5552c28f6937d2a2b873d06c6d09b96204722dd0
> author <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900
> committer <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900
> 
>  net/netfilter/nf_conntrack_proto_tcp.c |    4 +++-
>  net/netfilter/nf_conntrack_proto_udp.c |    4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> --- a/net/netfilter/nf_conntrack_proto_tcp.c
> +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> @@ -864,7 +864,9 @@ static int csum6(const struct sk_buff *s
>  {
>  	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
>  			       skb->len - dataoff, IPPROTO_TCP,
> -			       skb->ip_summed == CHECKSUM_HW ? skb->csum
> +			       skb->ip_summed == CHECKSUM_HW
> +			       ? csum_sub(skb->csum,
> +					  skb_checksum(skb, 0, dataoff, 0))
>  			       : skb_checksum(skb, dataoff, skb->len - dataoff,
>  					      0));
>  }
> diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
> --- a/net/netfilter/nf_conntrack_proto_udp.c
> +++ b/net/netfilter/nf_conntrack_proto_udp.c
> @@ -161,7 +161,9 @@ static int csum6(const struct sk_buff *s
>  {
>  	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
>  			       skb->len - dataoff, IPPROTO_UDP,
> -			       skb->ip_summed == CHECKSUM_HW ? skb->csum
> +			       skb->ip_summed == CHECKSUM_HW
> +			       ? csum_sub(skb->csum,
> +					  skb_checksum(skb, 0, dataoff, 0))
>  			       : skb_checksum(skb, dataoff, skb->len - dataoff,
>  					      0));
>  }

Re: IPv6 state match - possible bug.

[Yasuyuki KOZAKAI]

[-- Attachment #1: Type: Text/Plain, Size: 861 bytes --]

From: Ben Skeggs <darktama@iinet.net.au>
Date: Wed, 15 Feb 2006 14:15:29 +1100

> > > > checksumming with your eth0 driver might be broken.
> > > > I'm not sure why, but I saw some reports about checksum for a few weeks.
> > > Thank you!  This was indeed the problem.
> > 
> > Finally I got time to check codes for this and found bug.
> > If you have some time, could you try attached patch ?
> > I tested with sky2, but it's great if I can confirm that it works fine
> > with other device.
> I applied your patch to 2.6.16-rc3, and swapped back to the skge chip, I
> seem to have working IPv6 state matching now.  I set
> nf_conntrack_log_invalid again, and have not seen any invalid packet
> messages on dmesg at all.

Thanks for test. Harald or Patrick, please apply attached patch.
# I've added "Spotted by Ben Skeggs" to previous one.

-- Yasuyuki Kozakai

[-- Attachment #2: nfct_checksum.patch --]
[-- Type: Text/Plain, Size: 2076 bytes --]

[NETFILTER] nf_conntrack: Fix TCP/UDP checksum handling for IPv6 packet

If skb->ip_summed is CHECKSUM_HW here, skb->csum includes checksum
of actual IPv6 header and extension headers. Then such excess
checksum must be subtruct when nf_conntrack calculates TCP/UDP checksum
with psuedo IPv6 header. Spotted by Ben Skeggs.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

---
commit 7f5523d7f49865e62b683b0519408cf15a5b5624
tree e79868f93168aadd3e07e96605c351009019197f
parent 5552c28f6937d2a2b873d06c6d09b96204722dd0
author <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900
committer <kozakai@camellia.isl.rdc.toshiba.co.jp> Wed, 15 Feb 2006 03:16:28 +0900

 net/netfilter/nf_conntrack_proto_tcp.c |    4 +++-
 net/netfilter/nf_conntrack_proto_udp.c |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -864,7 +864,9 @@ static int csum6(const struct sk_buff *s
 {
 	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
 			       skb->len - dataoff, IPPROTO_TCP,
-			       skb->ip_summed == CHECKSUM_HW ? skb->csum
+			       skb->ip_summed == CHECKSUM_HW
+			       ? csum_sub(skb->csum,
+					  skb_checksum(skb, 0, dataoff, 0))
 			       : skb_checksum(skb, dataoff, skb->len - dataoff,
 					      0));
 }
diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
--- a/net/netfilter/nf_conntrack_proto_udp.c
+++ b/net/netfilter/nf_conntrack_proto_udp.c
@@ -161,7 +161,9 @@ static int csum6(const struct sk_buff *s
 {
 	return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,
 			       skb->len - dataoff, IPPROTO_UDP,
-			       skb->ip_summed == CHECKSUM_HW ? skb->csum
+			       skb->ip_summed == CHECKSUM_HW
+			       ? csum_sub(skb->csum,
+					  skb_checksum(skb, 0, dataoff, 0))
 			       : skb_checksum(skb, dataoff, skb->len - dataoff,
 					      0));
 }

Re: IPv6 state match - possible bug.

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> Thanks for test. Harald or Patrick, please apply attached patch.
> # I've added "Spotted by Ben Skeggs" to previous one.

Also applied, thanks.