2.6.9 NAT problem

2.6.9 NAT problem

[Giuliano Pochini]

I can't make NAT work on 2.6.9. Outgoing packets are translated and sent,
but incoming packets get rejected. pc4 is the other box (inside the NAT) and
host164-26... is the dynamic address of my machine:

20:42:20.132876 IP pc4.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
20:42:20.132876 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
20:42:20.446829 PPPoE  [ses 0x5198] [length 124 (4 extra bytes)] IP nsa.tin.it.domain > host164-26.pool21345.interbusiness.it.33115:  7213 0/1/0 (94)
20:42:20.446829 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it > nsa.tin.it: icmp 130: host164-26.pool21345.interbusiness.it udp port 33115 unreachable

I enable NAT with this commands:

echo "1" >/proc/sys/net/ipv4/ip_dynaddr
echo "1" >/proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s pc4 -d ! 192.168.1.0/24 -j MASQUERADE

I also tried SNAT with same results. I don't know if this info is useful:
all the connection couples shown by /proc/net/ip_conntrack are in
[UNREPLIED] state. I'm using iptables 1.2.11 and linux 2.6.9. All the above
works just fine with 2.6.8.1 and previous versions.

Linux Jay 2.6.9 #3 SMP Mon Dec 13 19:58:08 CET 2004 ppc unknown


--
Giuliano.

Re: 2.6.9 NAT problem

[Antonio Pérez]

Giuliano Pochini wrote:

>I can't make NAT work on 2.6.9. Outgoing packets are translated and sent,
>but incoming packets get rejected. pc4 is the other box (inside the NAT) and
>host164-26... is the dynamic address of my machine:
>
>20:42:20.132876 IP pc4.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
>20:42:20.132876 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
>20:42:20.446829 PPPoE  [ses 0x5198] [length 124 (4 extra bytes)] IP nsa.tin.it.domain > host164-26.pool21345.interbusiness.it.33115:  7213 0/1/0 (94)
>20:42:20.446829 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it > nsa.tin.it: icmp 130: host164-26.pool21345.interbusiness.it udp port 33115 unreachable
>
>I enable NAT with this commands:
>
>echo "1" >/proc/sys/net/ipv4/ip_dynaddr
>echo "1" >/proc/sys/net/ipv4/ip_forward
>iptables -t nat -A POSTROUTING -s pc4 -d ! 192.168.1.0/24 -j MASQUERADE
>
>I also tried SNAT with same results. I don't know if this info is useful:
>all the connection couples shown by /proc/net/ip_conntrack are in
>[UNREPLIED] state. I'm using iptables 1.2.11 and linux 2.6.9. All the above
>works just fine with 2.6.8.1 and previous versions.
>
>Linux Jay 2.6.9 #3 SMP Mon Dec 13 19:58:08 CET 2004 ppc unknown
>
>
>--
>Giuliano.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
add this:
echo 0 > /proc/sys/net/ipv4/tcp_bic
echo 0 > /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_vegas_conf_avoid

please , tell me if this work.

Re: 2.6.9 NAT problem

[Martin Josefsson]

On Mon, 13 Dec 2004, Giuliano Pochini wrote:

>
> I can't make NAT work on 2.6.9. Outgoing packets are translated and sent,
> but incoming packets get rejected. pc4 is the other box (inside the NAT) and
> host164-26... is the dynamic address of my machine:
>
> 20:42:20.132876 IP pc4.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
> 20:42:20.132876 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it.33115 > nsa.tin.it.domain:  7213+ AAAA? www.drweb32.com. (33)
> 20:42:20.446829 PPPoE  [ses 0x5198] [length 124 (4 extra bytes)] IP nsa.tin.it.domain > host164-26.pool21345.interbusiness.it.33115:  7213 0/1/0 (94)
> 20:42:20.446829 PPPoE  [ses 0x5198] IP host164-26.pool21345.interbusiness.it > nsa.tin.it: icmp 130: host164-26.pool21345.interbusiness.it udp port 33115 unreachable
>
> I enable NAT with this commands:
>
> echo "1" >/proc/sys/net/ipv4/ip_dynaddr
> echo "1" >/proc/sys/net/ipv4/ip_forward
> iptables -t nat -A POSTROUTING -s pc4 -d ! 192.168.1.0/24 -j MASQUERADE
>
> I also tried SNAT with same results. I don't know if this info is useful:
> all the connection couples shown by /proc/net/ip_conntrack are in
> [UNREPLIED] state. I'm using iptables 1.2.11 and linux 2.6.9. All the above
> works just fine with 2.6.8.1 and previous versions.

2.6.9 contains a large update to the connectiontracking code. One thing
that was changed is that it now verifies the checksum of tcp and udp
packets. I know of at least one user who has been bitten by this and what
looks like a broken sungem NIC.

Could you please try this:

modprobe ipt_LOG
echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

Then try again and then check the kernellog by executing 'dmesg', see if
it complains about bad checksums.

/Martin

Re: 2.6.9 NAT problem

[Giuliano Pochini]

On Tue, 14 Dec 2004, Martin Josefsson wrote:

> > I can't make NAT work on 2.6.9. Outgoing packets are translated and sent,
> > but incoming packets get rejected. pc4 is the other box (inside the NAT) and
> > host164-26... is the dynamic address of my machine:
>
> 2.6.9 contains a large update to the connectiontracking code. One thing
> that was changed is that it now verifies the checksum of tcp and udp
> packets. I know of at least one user who has been bitten by this and what
> looks like a broken sungem NIC.

The PMac uses the sungem driver indeed.


> Could you please try this:

I'll try that asap.


--
Giuliano.

Re: 2.6.9 NAT problem

[Giuliano Pochini]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 519 bytes --]



On Mon, 13 Dec 2004, [ISO-8859-1] Antonio Pérez wrote:

> Giuliano Pochini wrote:
>
> >I can't make NAT work on 2.6.9. Outgoing packets are translated and sent,
> >but incoming packets get rejected. pc4 is the other box (inside the NAT) and
> >host164-26... is the dynamic address of my machine:
> >[...]
> >
> add this:
> echo 0 > /proc/sys/net/ipv4/tcp_bic
> echo 0 > /proc/sys/net/ipv4/tcp_ecn
> echo 0 > /proc/sys/net/ipv4/tcp_vegas_conf_avoid
>
> please , tell me if this work.

Nope, it doesn't.


--
Giuliano.

Re: 2.6.9 NAT problem

[Giuliano Pochini]

On Tue, 14 Dec 2004, Martin Josefsson wrote:

> 2.6.9 contains a large update to the connectiontracking code. One thing
> that was changed is that it now verifies the checksum of tcp and udp
> packets. I know of at least one user who has been bitten by this and what
> looks like a broken sungem NIC.
>
> Could you please try this:
>
> modprobe ipt_LOG
> echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
>
> Then try again and then check the kernellog by executing 'dmesg', see if
> it complains about bad checksums.

Yes :(


--
Giuliano.

Re: 2.6.9 NAT problem

[Martin Josefsson]

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

On Tue, 2004-12-14 at 22:26, Giuliano Pochini wrote:

> > 2.6.9 contains a large update to the connectiontracking code. One thing
> > that was changed is that it now verifies the checksum of tcp and udp
> > packets. I know of at least one user who has been bitten by this and what
> > looks like a broken sungem NIC.
> >
> > Could you please try this:
> >
> > modprobe ipt_LOG
> > echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
> >
> > Then try again and then check the kernellog by executing 'dmesg', see if
> > it complains about bad checksums.
> 
> Yes :(

:( It seems there are silicon revisions of the apple sungem that produce
broken checksums. This is what we were worried about, we'll probably
submit a patch soon that removes the checksum checking,  then it'll
behave more like < 2.6.9-pre1

In the meantime you can use the patch below that simply comments that
code out. It's not diffed against 2.6.9 but should apply anyway.

Would be great if you could report a 'Yay' or 'Nay' on your success with
this patch.

--- linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.orig	2004-12-15 07:46:30.000000000 +0100
+++ linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_tcp.c	2004-12-15 07:47:34.000000000 +0100
@@ -800,7 +800,7 @@ static int tcp_error(struct sk_buff *skb
 	 * and moreover root might send raw packets.
 	 */
 	/* FIXME: Source route IP option packets --RR */
-	if (hooknum == NF_IP_PRE_ROUTING
+/*	if (hooknum == NF_IP_PRE_ROUTING
 	    && csum_tcpudp_magic(iph->saddr, iph->daddr, tcplen, IPPROTO_TCP,
 			         skb->ip_summed == CHECKSUM_HW ? skb->csum
 			      	 : skb_checksum(skb, iph->ihl*4, tcplen, 0))) {
@@ -808,7 +808,7 @@ static int tcp_error(struct sk_buff *skb
 			nf_log_packet(PF_INET, 0, skb, NULL, NULL, 
 				  "ip_ct_tcp: bad TCP checksum ");
 		return -NF_ACCEPT;
-	}
+	} */
 
 	/* Check TCP flags. */
 	tcpflags = (((u_int8_t *)th)[13] & ~(TH_ECE|TH_CWR));
--- linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_udp.c.orig	2004-12-15 07:46:37.000000000 +0100
+++ linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_udp.c	2004-12-15 07:47:59.000000000 +0100
@@ -119,7 +119,7 @@ static int udp_error(struct sk_buff *skb
 	 * because the semantic of CHECKSUM_HW is different there 
 	 * and moreover root might send raw packets.
 	 * FIXME: Source route IP option packets --RR */
-	if (hooknum == NF_IP_PRE_ROUTING
+/*	if (hooknum == NF_IP_PRE_ROUTING
 	    && csum_tcpudp_magic(iph->saddr, iph->daddr, udplen, IPPROTO_UDP,
 			         skb->ip_summed == CHECKSUM_HW ? skb->csum
 			      	 : skb_checksum(skb, iph->ihl*4, udplen, 0))) {
@@ -127,7 +127,7 @@ static int udp_error(struct sk_buff *skb
 			nf_log_packet(PF_INET, 0, skb, NULL, NULL, 
 				  "ip_ct_udp: bad UDP checksum ");
 		return -NF_ACCEPT;
-	}
+	} */
 	
 	return NF_ACCEPT;
 }
--- linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_icmp.c.orig	2004-12-15 07:46:43.000000000 +0100
+++ linux-2.6.10-rc1-ck1/net/ipv4/netfilter/ip_conntrack_proto_icmp.c	2004-12-15 07:48:57.000000000 +0100
@@ -218,7 +218,7 @@ icmp_error(struct sk_buff *skb, enum ip_
 	}
 
 	/* See ip_conntrack_proto_tcp.c */
-	if (hooknum != NF_IP_PRE_ROUTING)
+/*	if (hooknum != NF_IP_PRE_ROUTING)
 		goto checksum_skipped;
 
 	switch (skb->ip_summed) {
@@ -238,7 +238,7 @@ icmp_error(struct sk_buff *skb, enum ip_
 		}
 	default:
 		break;
-	}
+	} */
 
 checksum_skipped:
 	/*

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.9 NAT problem

[Giuliano Pochini]

On Wed, 15 Dec 2004, Martin Josefsson wrote:

> > > Then try again and then check the kernellog by executing 'dmesg', see if
> > > it complains about bad checksums.
> >
> > Yes :(
>
> :( It seems there are silicon revisions of the apple sungem that produce
> broken checksums. This is what we were worried about, we'll probably
> submit a patch soon that removes the checksum checking,  then it'll
> behave more like < 2.6.9-pre1
>
> In the meantime you can use the patch below that simply comments that
> code out. It's not diffed against 2.6.9 but should apply anyway.

Yes, the patch works fine.
I don't know anything about the network code, but since this is an
hardware problem, IMHO the workaround should go into the sungem driver. I
don't think that ip_conntrack should know anithing about the underlying
hardware. Is it possible to disable hw checksum and to use a sw one ?


--
Giuliano.

Re: 2.6.9 NAT problem

[Bill Davidsen]

Antonio Pérez wrote:

> add this:
> echo 0 > /proc/sys/net/ipv4/tcp_bic
> echo 0 > /proc/sys/net/ipv4/tcp_ecn
> echo 0 > /proc/sys/net/ipv4/tcp_vegas_conf_avoid

I've seen this and similar advice for other problems, and have disabled 
ecn for several systems with networking ailments myself. Would it be 
better to have some of these off by default rather than have multiple 
versions of these problems appear into the future? Is there some common 
case where these not only work but provide a significant benefit so 
great it justifies being the default?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.9 NAT problem

[Bill Davidsen]

Bodo Eggert wrote:
> Bill Davidsen wrote:
> 
>>Antonio Pérez wrote:
> 
> 
>>>add this:
>>>echo 0 > /proc/sys/net/ipv4/tcp_bic
>>>echo 0 > /proc/sys/net/ipv4/tcp_ecn
>>>echo 0 > /proc/sys/net/ipv4/tcp_vegas_conf_avoid
>>
>>I've seen this and similar advice for other problems, and have disabled=
>> 
>>ecn for several systems with networking ailments myself. Would it be
>>better to have some of these off by default rather than have multiple
>>versions of these problems appear into the future?
> 
> 
> Disabeling ecn is a workaround for b0rken firewalls and may result in
> using more bandwidth than nescensary. If disabeling ecn helps, dump the
> firewall and get something that supports basic internet standards (or
> ask the owner to do this).
> 
Like many other parameters, ecn can improve performance but may result 
in a non-functional network. Based on that I still think it's better for 
the default to be "works" and use of ecn or other tuning parameters such 
as reducing timeouts should be "tuning" instead.

Adding a few printk's seems to show that ecn is not so common that it 
needs to be on by default. I suspect that the main use of ecn code is in 
fighting with those broken routers and firewalls rather than improving 
performance.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.9 NAT problem

[Bodo Eggert]

Bill Davidsen wrote:
> Antonio Pérez wrote:

>> add this:
>> echo 0 > /proc/sys/net/ipv4/tcp_bic
>> echo 0 > /proc/sys/net/ipv4/tcp_ecn
>> echo 0 > /proc/sys/net/ipv4/tcp_vegas_conf_avoid
> 
> I've seen this and similar advice for other problems, and have disabled=
>  
> ecn for several systems with networking ailments myself. Would it be
> better to have some of these off by default rather than have multiple
> versions of these problems appear into the future?

Disabeling ecn is a workaround for b0rken firewalls and may result in
using more bandwidth than nescensary. If disabeling ecn helps, dump the
firewall and get something that supports basic internet standards (or
ask the owner to do this).