Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
Patrick McHardy wrote:
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
Worked here.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-17 23:00:55 +01:00
+++ edited/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-28 02:13:06 +01:00
@@ -105,7 +105,7 @@
return 0;
iph = (struct iphdr *)((*pskb)->data + iphdroff);
- hdr = (struct tcphdr *)((*pskb)->data + iph->ihl*4);
+ hdr = (struct tcphdr *)((*pskb)->data + hdroff);
if (maniptype == IP_NAT_MANIP_SRC) {
/* Get rid of src ip and src pt */
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
Patrick McHardy wrote:
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
Worked here.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-17 23:00:55 +01:00
+++ edited/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-28 02:13:06 +01:00
@@ -105,7 +105,7 @@
return 0;
iph = (struct iphdr *)((*pskb)-data + iphdroff);
- hdr = (struct tcphdr *)((*pskb)-data + iph-ihl*4);
+ hdr = (struct tcphdr *)((*pskb)-data + hdroff);
if (maniptype == IP_NAT_MANIP_SRC) {
/* Get rid of src ip and src pt */
--
-bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
last possible moment - but no longer -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Fri, Jan 28, 2005 at 02:33:10AM +0100, Patrick McHardy wrote: > Here is the fix for everyone. Please report back if it doesn't > solve the problem. Thanks. > > [ ... snip ... ] Success!!! Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Fri, Jan 28, 2005 at 02:33:10AM +0100, Patrick McHardy wrote: Here is the fix for everyone. Please report back if it doesn't solve the problem. Thanks. [ ... snip ... ] Success!!! Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Fri, 2005-01-28 at 02:33 +0100, Patrick McHardy wrote: > David S. Miller wrote: > > >I've forwarded this to netfilter-devel for inspection. > >Thanks for collecting all the data points so well. > > > Here is the fix for everyone. Please report back if it doesn't > solve the problem. Thanks. Verified by nfsim (the ICMP tests used UDP, I've just added TCP and ICMP, and will do SCTP). Thanks, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-17 23:00:55 +01:00
+++ edited/net/ipv4/netfilter/ip_nat_proto_tcp.c2005-01-28 02:13:06
+01:00
@@ -105,7 +105,7 @@
return 0;
iph = (struct iphdr *)((*pskb)->data + iphdroff);
- hdr = (struct tcphdr *)((*pskb)->data + iph->ihl*4);
+ hdr = (struct tcphdr *)((*pskb)->data + hdroff);
if (maniptype == IP_NAT_MANIP_SRC) {
/* Get rid of src ip and src pt */
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
I've forwarded this to netfilter-devel for inspection. Thanks for collecting all the data points so well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
I just got an interesting "I see these problems too" report. It may provide a useful clue. According to "Art Haas" <[EMAIL PROTECTED]>: > I'm running the current BK kernel now, and I'm not seeing the problems > right now because, I found, I do not have some of the IP masquerading > modules installed on my machine. When these modules get installed then > the cvs/rsync problems appear. I do have CONFIG_IP_NF_TARGET_MASQUERADE=y on the system where I'm seeing this, though it's not doing anything just now. Haven't yet made time to see if disabling it improves things ... but if that's a factor, it could explain why more people aren't suffering with this problem. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On 2005-01-27 at 11:28:48, David Brownell wrote: > > Indeed, I had to shuffle my machines around a bit to get a proof that > > something is broken, but now I can confirm the above with a connection > > to cvs.sourceforge.net: > > Thanks for confirming it wasn't just me ... I confess I'm a bit > surprised more folk haven't reported this yet! > > Your symptoms are exactly like those I saw, just with a different > mission-critical application: CVS, not SMTP. Did you happen to > notice whether CVS pulls worked, when pushes (like this) failed? I'm familiar with symptoms arising from various stochastic/assymetric networking problems with larger frames, I had cable :) This was a pull (update), BTW, CVS can send more data in this situation too. But it turned painfully obvious when trying to send mail to LK via SMTP. Oh, but while plain rc2 may have this problem, this particular endpoint had rc2-bk3 running. I also chose to set the ethernet MTU to 1492 as an easy workaround... -- Janos | romfs is at http://romfs.sourceforge.net/ | Don't talk about silence. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Thursday 27 January 2005 1:02 am, Janos Farkas wrote: > On 2005-01-25 at 10:54:36, David Brownell wrote: > > On Tuesday 25 January 2005 10:35 am, David Ford wrote: > > > PMTU bug -- or better said, bad firewall admin who blocks all ICMP. > > > > PMTU bug, sure -- but one that came late in RC2. Remember: same firewall > > in both cases, but only RC2 breaks. The ICMP packet has landed in > > the RC2 system, which ignores it. 2.6.10 handled it correctly... I > > suspect one of the TCP cleanups borked this. And in fact, I'm pretty sure RC1 handled it fine too. This failure appeared in a BK pull I did a couple days before RC2, and installing it clobbered a "more virgin" RC1 install; so it's hard to verify. It took a while to track the failure mode down to being PMTU related, but the only TCP-related changes I noticed in what I pulled sure seemed like cleanups (removing some "duplicated" state). > > My current workaround is "ifconfig eth0 mtu 1492" but that's not > > something I'd expect to keep. > > Indeed, I had to shuffle my machines around a bit to get a proof that > something is broken, but now I can confirm the above with a connection > to cvs.sourceforge.net: Thanks for confirming it wasn't just me ... I confess I'm a bit surprised more folk haven't reported this yet! Your symptoms are exactly like those I saw, just with a different mission-critical application: CVS, not SMTP. Did you happen to notice whether CVS pulls worked, when pushes (like this) failed? - Dave > ... > > (the PPPoE gateway notifies the host about the PMTU issue, one for each > segment) > > 08:05:45.265330 IP (tos 0xc0, ttl 128, id 17970, offset 0, flags [none], > length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 > unreachable - need to frag (mtu 1492) > 08:05:45.265453 IP (tos 0xc0, ttl 128, id 17971, offset 0, flags [none], > length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 > unreachable - need to frag (mtu 1492) > > (the source host sends the full frame again...?) > > 08:05:45.770331 IP (tos 0x0, ttl 64, id 21544, offset 0, flags [DF], length: > 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) > ack 526 win 1728 > 08:05:45.770900 IP (tos 0xc0, ttl 128, id 17972, offset 0, flags [none], > length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 > unreachable - need to frag (mtu 1492) > > (and looping goes on..) > > 08:05:46.783148 IP (tos 0x0, ttl 64, id 21546, offset 0, flags [DF], length: > 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) > ack 526 win 1728 > 08:05:46.783752 IP (tos 0xc0, ttl 128, id 17973, offset 0, flags [none], > length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 > unreachable - need to frag (mtu 1492) > 08:05:48.808861 IP (tos 0x0, ttl 64, id 21548, offset 0, flags [DF], length: > 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) > ack 526 win 1728 > 08:05:48.809882 IP (tos 0xc0, ttl 128, id 17974, offset 0, flags [none], > length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 > unreachable - need to frag (mtu 1492) > > ... > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On 2005-01-25 at 10:54:36, David Brownell wrote: > On Tuesday 25 January 2005 10:35 am, David Ford wrote: > > PMTU bug -- or better said, bad firewall admin who blocks all ICMP. > > PMTU bug, sure -- but one that came late in RC2. Remember: same firewall > in both cases, but only RC2 breaks. The ICMP packet has landed in > the RC2 system, which ignores it. 2.6.10 handled it correctly... I > suspect one of the TCP cleanups borked this. > > My current workaround is "ifconfig eth0 mtu 1492" but that's not > something I'd expect to keep. Indeed, I had to shuffle my machines around a bit to get a proof that something is broken, but now I can confirm the above with a connection to cvs.sourceforge.net: 192.168.59.10 is the 2.6.11-rc2 host, 192.168.59.1 is the (now pre-rc2) gateway with a PPPoE 1492 mtu/pmtu host. 59.10 does not run any firewall/packet filter. (almost full-fledged perfect three-way handshake) 08:05:43.046546 IP (tos 0x0, ttl 64, id 21526, offset 0, flags [DF], length: 60) 192.168.59.10.29612 > 66.35.250.207.2401: SWE [tcp sum ok] 933042757:933042757(0) win 5840 08:05:43.249819 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], length: 60) 66.35.250.207.2401 > 192.168.59.10.29612: S [tcp sum ok] 2956308271:2956308271(0) ack 933042758 win 5792 08:05:43.249881 IP (tos 0x0, ttl 64, id 21528, offset 0, flags [DF], length: 52) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] ack 1 win 1460 (CVS protocol starts) 08:05:43.363697 IP (tos 0x0, ttl 64, id 21530, offset 0, flags [DF], length: 116) 192.168.59.10.29612 > 66.35.250.207.2401: P [tcp sum ok] 1:65(64) ack 1 win 1460 08:05:43.568504 IP (tos 0x0, ttl 45, id 14633, offset 0, flags [DF], length: 52) 66.35.250.207.2401 > 192.168.59.10.29612: . [tcp sum ok] ack 65 win 5792 08:05:43.964094 IP (tos 0x0, ttl 45, id 14634, offset 0, flags [DF], length: 63) 66.35.250.207.2401 > 192.168.59.10.29612: P [tcp sum ok] 1:12(11) ack 65 win 5792 08:05:43.964121 IP (tos 0x0, ttl 64, id 21532, offset 0, flags [DF], length: 52) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] ack 12 win 1460 08:05:43.964258 IP (tos 0x0, ttl 64, id 21534, offset 0, flags [DF], length: 440) 192.168.59.10.29612 > 66.35.250.207.2401: P [tcp sum ok] 65:453(388) ack 12 win 1460 08:05:44.184893 IP (tos 0x0, ttl 45, id 14635, offset 0, flags [DF], length: 52) 66.35.250.207.2401 > 192.168.59.10.29612: . [tcp sum ok] ack 453 win 6432 08:05:44.192050 IP (tos 0x0, ttl 45, id 14636, offset 0, flags [DF], length: 566) 66.35.250.207.2401 > 192.168.59.10.29612: P [tcp sum ok] 12:526(514) ack 453 win 6432 08:05:44.192274 IP (tos 0x0, ttl 64, id 21536, offset 0, flags [DF], length: 65) 192.168.59.10.29612 > 66.35.250.207.2401: P [tcp sum ok] 453:466(13) ack 526 win 1728 08:05:44.432709 IP (tos 0x0, ttl 45, id 14637, offset 0, flags [DF], length: 52) 66.35.250.207.2401 > 192.168.59.10.29612: . [tcp sum ok] ack 466 win 6432 08:05:44.893674 IP (tos 0x0, ttl 64, id 21538, offset 0, flags [DF], length: 85) 192.168.59.10.29612 > 66.35.250.207.2401: P [tcp sum ok] 466:499(33) ack 526 win 1728 08:05:45.094985 IP (tos 0x0, ttl 45, id 14638, offset 0, flags [DF], length: 52) 66.35.250.207.2401 > 192.168.59.10.29612: . [tcp sum ok] ack 499 win 6432 (first ethernet frame-sized segment is about to be sent) 08:05:45.264633 IP (tos 0x0, ttl 64, id 21540, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 08:05:45.264694 IP (tos 0x0, ttl 64, id 21542, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 1947:3395(1448) ack 526 win 1728 (the PPPoE gateway notifies the host about the PMTU issue, one for each segment) 08:05:45.265330 IP (tos 0xc0, ttl 128, id 17970, offset 0, flags [none], length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) 08:05:45.265453 IP (tos 0xc0, ttl 128, id 17971, offset 0, flags [none], length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) (the source host sends the full frame again...?) 08:05:45.770331 IP (tos 0x0, ttl 64, id 21544, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 08:05:45.770900 IP (tos 0xc0, ttl 128, id 17972, offset 0, flags [none], length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) (and looping goes on..) 08:05:46.783148 IP (tos 0x0, ttl 64, id 21546, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 > 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 08:05:46.783752 IP (tos 0xc0, ttl 128, id 17973, offset 0, flags [none], length: 576) 192.168.59.1 > 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) 08:05:48.808861 IP (tos 0x0, ttl 64, id 21548, offset 0, flags [DF],
2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On 2005-01-25 at 10:54:36, David Brownell wrote: On Tuesday 25 January 2005 10:35 am, David Ford wrote: PMTU bug -- or better said, bad firewall admin who blocks all ICMP. PMTU bug, sure -- but one that came late in RC2. Remember: same firewall in both cases, but only RC2 breaks. The ICMP packet has landed in the RC2 system, which ignores it. 2.6.10 handled it correctly... I suspect one of the TCP cleanups borked this. My current workaround is ifconfig eth0 mtu 1492 but that's not something I'd expect to keep. Indeed, I had to shuffle my machines around a bit to get a proof that something is broken, but now I can confirm the above with a connection to cvs.sourceforge.net: 192.168.59.10 is the 2.6.11-rc2 host, 192.168.59.1 is the (now pre-rc2) gateway with a PPPoE 1492 mtu/pmtu host. 59.10 does not run any firewall/packet filter. (almost full-fledged perfect three-way handshake) 08:05:43.046546 IP (tos 0x0, ttl 64, id 21526, offset 0, flags [DF], length: 60) 192.168.59.10.29612 66.35.250.207.2401: SWE [tcp sum ok] 933042757:933042757(0) win 5840 mss 1460,sackOK,timestamp 2707027 0,nop,wscale 2 08:05:43.249819 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], length: 60) 66.35.250.207.2401 192.168.59.10.29612: S [tcp sum ok] 2956308271:2956308271(0) ack 933042758 win 5792 mss 1460,sackOK,timestamp 312382981 2707027,nop,wscale 0 08:05:43.249881 IP (tos 0x0, ttl 64, id 21528, offset 0, flags [DF], length: 52) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] ack 1 win 1460 nop,nop,timestamp 2707230 312382981 (CVS protocol starts) 08:05:43.363697 IP (tos 0x0, ttl 64, id 21530, offset 0, flags [DF], length: 116) 192.168.59.10.29612 66.35.250.207.2401: P [tcp sum ok] 1:65(64) ack 1 win 1460 nop,nop,timestamp 2707344 312382981 08:05:43.568504 IP (tos 0x0, ttl 45, id 14633, offset 0, flags [DF], length: 52) 66.35.250.207.2401 192.168.59.10.29612: . [tcp sum ok] ack 65 win 5792 nop,nop,timestamp 312383013 2707344 08:05:43.964094 IP (tos 0x0, ttl 45, id 14634, offset 0, flags [DF], length: 63) 66.35.250.207.2401 192.168.59.10.29612: P [tcp sum ok] 1:12(11) ack 65 win 5792 nop,nop,timestamp 312383053 2707344 08:05:43.964121 IP (tos 0x0, ttl 64, id 21532, offset 0, flags [DF], length: 52) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] ack 12 win 1460 nop,nop,timestamp 2707945 312383053 08:05:43.964258 IP (tos 0x0, ttl 64, id 21534, offset 0, flags [DF], length: 440) 192.168.59.10.29612 66.35.250.207.2401: P [tcp sum ok] 65:453(388) ack 12 win 1460 nop,nop,timestamp 2707945 312383053 08:05:44.184893 IP (tos 0x0, ttl 45, id 14635, offset 0, flags [DF], length: 52) 66.35.250.207.2401 192.168.59.10.29612: . [tcp sum ok] ack 453 win 6432 nop,nop,timestamp 312383075 2707945 08:05:44.192050 IP (tos 0x0, ttl 45, id 14636, offset 0, flags [DF], length: 566) 66.35.250.207.2401 192.168.59.10.29612: P [tcp sum ok] 12:526(514) ack 453 win 6432 nop,nop,timestamp 312383075 2707945 08:05:44.192274 IP (tos 0x0, ttl 64, id 21536, offset 0, flags [DF], length: 65) 192.168.59.10.29612 66.35.250.207.2401: P [tcp sum ok] 453:466(13) ack 526 win 1728 nop,nop,timestamp 2708174 312383075 08:05:44.432709 IP (tos 0x0, ttl 45, id 14637, offset 0, flags [DF], length: 52) 66.35.250.207.2401 192.168.59.10.29612: . [tcp sum ok] ack 466 win 6432 nop,nop,timestamp 312383100 2708174 08:05:44.893674 IP (tos 0x0, ttl 64, id 21538, offset 0, flags [DF], length: 85) 192.168.59.10.29612 66.35.250.207.2401: P [tcp sum ok] 466:499(33) ack 526 win 1728 nop,nop,timestamp 2708876 312383100 08:05:45.094985 IP (tos 0x0, ttl 45, id 14638, offset 0, flags [DF], length: 52) 66.35.250.207.2401 192.168.59.10.29612: . [tcp sum ok] ack 499 win 6432 nop,nop,timestamp 312383166 2708876 (first ethernet frame-sized segment is about to be sent) 08:05:45.264633 IP (tos 0x0, ttl 64, id 21540, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 nop,nop,timestamp 2709247 312383166 08:05:45.264694 IP (tos 0x0, ttl 64, id 21542, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 1947:3395(1448) ack 526 win 1728 nop,nop,timestamp 2709247 312383166 (the PPPoE gateway notifies the host about the PMTU issue, one for each segment) 08:05:45.265330 IP (tos 0xc0, ttl 128, id 17970, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) 08:05:45.265453 IP (tos 0xc0, ttl 128, id 17971, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) (the source host sends the full frame again...?) 08:05:45.770331 IP (tos 0x0, ttl 64, id 21544, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 nop,nop,timestamp 2709754 312383166 08:05:45.770900 IP (tos 0xc0, ttl
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Thursday 27 January 2005 1:02 am, Janos Farkas wrote: On 2005-01-25 at 10:54:36, David Brownell wrote: On Tuesday 25 January 2005 10:35 am, David Ford wrote: PMTU bug -- or better said, bad firewall admin who blocks all ICMP. PMTU bug, sure -- but one that came late in RC2. Remember: same firewall in both cases, but only RC2 breaks. The ICMP packet has landed in the RC2 system, which ignores it. 2.6.10 handled it correctly... I suspect one of the TCP cleanups borked this. And in fact, I'm pretty sure RC1 handled it fine too. This failure appeared in a BK pull I did a couple days before RC2, and installing it clobbered a more virgin RC1 install; so it's hard to verify. It took a while to track the failure mode down to being PMTU related, but the only TCP-related changes I noticed in what I pulled sure seemed like cleanups (removing some duplicated state). My current workaround is ifconfig eth0 mtu 1492 but that's not something I'd expect to keep. Indeed, I had to shuffle my machines around a bit to get a proof that something is broken, but now I can confirm the above with a connection to cvs.sourceforge.net: Thanks for confirming it wasn't just me ... I confess I'm a bit surprised more folk haven't reported this yet! Your symptoms are exactly like those I saw, just with a different mission-critical application: CVS, not SMTP. Did you happen to notice whether CVS pulls worked, when pushes (like this) failed? - Dave ... (the PPPoE gateway notifies the host about the PMTU issue, one for each segment) 08:05:45.265330 IP (tos 0xc0, ttl 128, id 17970, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) 08:05:45.265453 IP (tos 0xc0, ttl 128, id 17971, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) (the source host sends the full frame again...?) 08:05:45.770331 IP (tos 0x0, ttl 64, id 21544, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 nop,nop,timestamp 2709754 312383166 08:05:45.770900 IP (tos 0xc0, ttl 128, id 17972, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) (and looping goes on..) 08:05:46.783148 IP (tos 0x0, ttl 64, id 21546, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 nop,nop,timestamp 2710768 312383166 08:05:46.783752 IP (tos 0xc0, ttl 128, id 17973, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) 08:05:48.808861 IP (tos 0x0, ttl 64, id 21548, offset 0, flags [DF], length: 1500) 192.168.59.10.29612 66.35.250.207.2401: . [tcp sum ok] 499:1947(1448) ack 526 win 1728 nop,nop,timestamp 2712796 312383166 08:05:48.809882 IP (tos 0xc0, ttl 128, id 17974, offset 0, flags [none], length: 576) 192.168.59.1 192.168.59.10: icmp 556: 66.35.250.207 unreachable - need to frag (mtu 1492) ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On 2005-01-27 at 11:28:48, David Brownell wrote: Indeed, I had to shuffle my machines around a bit to get a proof that something is broken, but now I can confirm the above with a connection to cvs.sourceforge.net: Thanks for confirming it wasn't just me ... I confess I'm a bit surprised more folk haven't reported this yet! Your symptoms are exactly like those I saw, just with a different mission-critical application: CVS, not SMTP. Did you happen to notice whether CVS pulls worked, when pushes (like this) failed? I'm familiar with symptoms arising from various stochastic/assymetric networking problems with larger frames, I had cable :) This was a pull (update), BTW, CVS can send more data in this situation too. But it turned painfully obvious when trying to send mail to LK via SMTP. Oh, but while plain rc2 may have this problem, this particular endpoint had rc2-bk3 running. I also chose to set the ethernet MTU to 1492 as an easy workaround... -- Janos | romfs is at http://romfs.sourceforge.net/ | Don't talk about silence. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
I just got an interesting I see these problems too report. It may provide a useful clue. According to Art Haas [EMAIL PROTECTED]: I'm running the current BK kernel now, and I'm not seeing the problems right now because, I found, I do not have some of the IP masquerading modules installed on my machine. When these modules get installed then the cvs/rsync problems appear. I do have CONFIG_IP_NF_TARGET_MASQUERADE=y on the system where I'm seeing this, though it's not doing anything just now. Haven't yet made time to see if disabling it improves things ... but if that's a factor, it could explain why more people aren't suffering with this problem. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
I've forwarded this to netfilter-devel for inspection. Thanks for collecting all the data points so well. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/ipv4/netfilter/ip_nat_proto_tcp.c 2005-01-17 23:00:55 +01:00
+++ edited/net/ipv4/netfilter/ip_nat_proto_tcp.c2005-01-28 02:13:06
+01:00
@@ -105,7 +105,7 @@
return 0;
iph = (struct iphdr *)((*pskb)-data + iphdroff);
- hdr = (struct tcphdr *)((*pskb)-data + iph-ihl*4);
+ hdr = (struct tcphdr *)((*pskb)-data + hdroff);
if (maniptype == IP_NAT_MANIP_SRC) {
/* Get rid of src ip and src pt */
Re: 2.6.11-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)
On Fri, 2005-01-28 at 02:33 +0100, Patrick McHardy wrote: David S. Miller wrote: I've forwarded this to netfilter-devel for inspection. Thanks for collecting all the data points so well. Here is the fix for everyone. Please report back if it doesn't solve the problem. Thanks. Verified by nfsim (the ICMP tests used UDP, I've just added TCP and ICMP, and will do SCTP). Thanks, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Tuesday 25 January 2005 10:35 am, David Ford wrote: > PMTU bug -- or better said, bad firewall admin who blocks all ICMP. PMTU bug, sure -- but one that came late in RC2. Remember: same firewall in both cases, but only RC2 breaks. The ICMP packet has landed in the RC2 system, which ignores it. 2.6.10 handled it correctly... I suspect one of the TCP cleanups borked this. My current workaround is "ifconfig eth0 mtu 1492" but that's not something I'd expect to keep. - Dave > http://blue-labs.org/clue/mtu-mss.php > > -david > > David Brownell wrote: > > >I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). > >But oddly enough, only for sending mail, not reading it; and not through > >other (reading) applications... it's a regression with respect to rc1 and > >earlier kernels. Basically, it can only send REALLY TINY emails... > > > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
PMTU bug -- or better said, bad firewall admin who blocks all ICMP. http://blue-labs.org/clue/mtu-mss.php -david David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On Tue, Jan 25, 2005 at 02:46:56AM +0100, Petr Vandrovec wrote: > On 25 Jan 05 at 1:41, Sytse Wielinga wrote: > > Linus, could you please put skb_copy_datagram back in place? It's not used > > anymore in the kernel, but the vmnet module (in vmware) still uses this > > interface to skb_copy_datagram_iovec. > > There is no reason for doing this. Just grab latest vmmon & vmnet > from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, > and enjoy latest and greatest modules. Besides this one you'll get lot > of other fixes and improvements for free ;-) I'm very sorry, you're completely right. That version uses skb_copy_datagram_iovec. I'll file a bug for gentoo instead, that it needs to update from 88 to 89. On the other hand, though, I would think it would be a good idea to leave this function in until after 2.6.11, so that distributions and people have plenty of time to update their vmware. After all, it's not like we'd be missing out on an important fix or something; we're just moving a couple of bytes out of the kernel into vmnet. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On Tue, Jan 25, 2005 at 02:46:56AM +0100, Petr Vandrovec wrote: On 25 Jan 05 at 1:41, Sytse Wielinga wrote: Linus, could you please put skb_copy_datagram back in place? It's not used anymore in the kernel, but the vmnet module (in vmware) still uses this interface to skb_copy_datagram_iovec. There is no reason for doing this. Just grab latest vmmon vmnet from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, and enjoy latest and greatest modules. Besides this one you'll get lot of other fixes and improvements for free ;-) I'm very sorry, you're completely right. That version uses skb_copy_datagram_iovec. I'll file a bug for gentoo instead, that it needs to update from 88 to 89. On the other hand, though, I would think it would be a good idea to leave this function in until after 2.6.11, so that distributions and people have plenty of time to update their vmware. After all, it's not like we'd be missing out on an important fix or something; we're just moving a couple of bytes out of the kernel into vmnet. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
PMTU bug -- or better said, bad firewall admin who blocks all ICMP. http://blue-labs.org/clue/mtu-mss.php -david David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Tuesday 25 January 2005 10:35 am, David Ford wrote: PMTU bug -- or better said, bad firewall admin who blocks all ICMP. PMTU bug, sure -- but one that came late in RC2. Remember: same firewall in both cases, but only RC2 breaks. The ICMP packet has landed in the RC2 system, which ignores it. 2.6.10 handled it correctly... I suspect one of the TCP cleanups borked this. My current workaround is ifconfig eth0 mtu 1492 but that's not something I'd expect to keep. - Dave http://blue-labs.org/clue/mtu-mss.php -david David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
On Tue, Jan 25, 2005 at 01:41:17AM +0100, Sytse Wielinga wrote: > Linus, could you please put skb_copy_datagram back in place? It's not used > anymore in the kernel, but the vmnet module (in vmware) still uses this > interface to skb_copy_datagram_iovec. > > Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet, > but I assume it's okay. I'll test it right after sending this mail and report > back here if something goes wrong. Just fix vmware. Or upgrade to a fixed version that Petr mentioned already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On 25 Jan 05 at 1:41, Sytse Wielinga wrote: > Linus, could you please put skb_copy_datagram back in place? It's not used > anymore in the kernel, but the vmnet module (in vmware) still uses this > interface to skb_copy_datagram_iovec. There is no reason for doing this. Just grab latest vmmon & vmnet from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, and enjoy latest and greatest modules. Besides this one you'll get lot of other fixes and improvements for free ;-) Petr Vandrovec - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
Linus, could you please put skb_copy_datagram back in place? It's not used
anymore in the kernel, but the vmnet module (in vmware) still uses this
interface to skb_copy_datagram_iovec.
Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
but I assume it's okay. I'll test it right after sending this mail and report
back here if something goes wrong.
Sytse
diff -ru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-01-25 01:27:00.0 +0100
+++ b/include/linux/skbuff.h2005-01-25 01:31:20.0 +0100
@@ -1086,6 +1086,8 @@
int noblock, int *err);
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
int size);
diff -ru a/net/core/datagram.c b/net/core/datagram.c
--- a/net/core/datagram.c 2005-01-25 01:27:01.0 +0100
+++ b/net/core/datagram.c 2005-01-25 01:31:20.0 +0100
@@ -199,6 +199,19 @@
kfree_skb(skb);
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, , size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
* @skb - buffer to copy
@@ -477,6 +490,7 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
EXPORT_SYMBOL(skb_recv_datagram);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Monday 24 January 2005 10:05 am, Martin Josefsson wrote: > On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: > > ... > > - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 > > - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... > > > > Naturally the connection goes nowhere. > > Is there a firewall on this machine? And if so, do you allow inbound > icmp? It's behind a firewall; no firewall on that box though. The only difference between a working RC1 and non-working RC2 was the kernel. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2 (compile stats)
Linux 2.6 Compile Statistics (gcc 3.4.1) Web page with links to complete details: http://developer.osdl.org/cherry/compile/ Kernel bzImagebzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --- --- - 2.6.11-rc218w/0e 0w/0e 365w/0e6w/0e 22w/0e440w/0e 2.6.11-rc120w/0e 0w/0e 497w/0e6w/0e 22w/0e577w/0e 2.6.1013w/0e 0w/0e 778w/0e6w/0e 15w/0e861w/0e Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1) KernelbzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --- -- 2.6.11-rc2-mm1 15w/0e 0w/0e 306w/14e 6w/0e 18w/0e294w/0e 2.6.11-rc1-mm2 21w/0e 0w/0e 316w/9e6w/0e 22w/0e294w/0e 2.6.11-rc1-mm1 21w/0e 0w/0e 319w/0e6w/0e 23w/0e298w/0e 2.6.10-mm3 21w/0e 0w/0e 320w/0e6w/0e 23w/0e299w/0e 2.6.10-mm2 21w/0e 0w/0e 440w/0e6w/0e 23w/0e420w/0e 2.6.10-mm1 12w/0e 0w/0e 414w/0e6w/0e 17w/0e399w/0e Daily compiles (ia32): http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt Latest changes in Linus' bitkeeper tree: http://linux.bkbits.net:8080/linux-2.5 John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
Hi,
On Monday 24 January 2005 11.43, Adrian Bunk wrote:
> On Sun, Jan 23, 2005 at 10:11:45PM +0100, Magnus Määttä wrote:
> > Hello
>
> Hi Magnus,
>
> > It doesn't compile here, here's the error:
> >
> > CC net/sched/sch_generic.o
> > net/sched/sch_generic.c: In function `qdisc_restart':
> > net/sched/sch_generic.c:128: error: label `requeue' used but not
> > defined
> > make[2]: *** [net/sched/sch_generic.o] Error 1
> > make[1]: *** [net/sched] Error 2
> > make: *** [net] Error 2
>
> I wasn't able to reproduce your problem.
>
> Do you have any patches applied on top of 2.6.11-rc2 ?
Sorry about the noise. I forgot that I had Ingo's realtime preempt
patch applied (just saw that it was fixed anyway). I guess this is
what happens when you're compiling on several systems at once
(patched vs. unpatched ones).
Magnus
--
panic("huh?\n");
linux-2.2.16/arch/i386/kernel/smp.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: > I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). > But oddly enough, only for sending mail, not reading it; and not through > other (reading) applications... it's a regression with respect to rc1 and > earlier kernels. Basically, it can only send REALLY TINY emails... > > What ethereal shows me is roughly: > > - SMTP connect, initial handshake, ok (ACKed later) > - Send two 1500 byte Ethernet packets > - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 > - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... > > Naturally the connection goes nowhere. Is there a firewall on this machine? And if so, do you allow inbound icmp? -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sun, Jan 23, 2005 at 10:11:45PM +0100, Magnus Määttä wrote: > Hello Hi Magnus, > > It doesn't compile here, here's the error: > > CC net/sched/sch_generic.o > net/sched/sch_generic.c: In function `qdisc_restart': > net/sched/sch_generic.c:128: error: label `requeue' used but not > defined > make[2]: *** [net/sched/sch_generic.o] Error 1 > make[1]: *** [net/sched] Error 2 > make: *** [net] Error 2 > > > >From .config: >... I wasn't able to reproduce your problem. Do you have any patches applied on top of 2.6.11-rc2 ? If not, please send: - your complete .config - the output of bash scripts/ver_linux TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... What ethereal shows me is roughly: - SMTP connect, initial handshake, ok (ACKed later) - Send two 1500 byte Ethernet packets - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. Is there a firewall on this machine? And if so, do you allow inbound icmp? -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
Hi, On Monday 24 January 2005 11.43, Adrian Bunk wrote: On Sun, Jan 23, 2005 at 10:11:45PM +0100, Magnus Määttä wrote: Hello Hi Magnus, It doesn't compile here, here's the error: CC net/sched/sch_generic.o net/sched/sch_generic.c: In function `qdisc_restart': net/sched/sch_generic.c:128: error: label `requeue' used but not defined make[2]: *** [net/sched/sch_generic.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 I wasn't able to reproduce your problem. Do you have any patches applied on top of 2.6.11-rc2 ? Sorry about the noise. I forgot that I had Ingo's realtime preempt patch applied (just saw that it was fixed anyway). I guess this is what happens when you're compiling on several systems at once (patched vs. unpatched ones). Magnus -- panic(huh?\n); linux-2.2.16/arch/i386/kernel/smp.c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2 (compile stats)
Linux 2.6 Compile Statistics (gcc 3.4.1) Web page with links to complete details: http://developer.osdl.org/cherry/compile/ Kernel bzImagebzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --- --- - 2.6.11-rc218w/0e 0w/0e 365w/0e6w/0e 22w/0e440w/0e 2.6.11-rc120w/0e 0w/0e 497w/0e6w/0e 22w/0e577w/0e 2.6.1013w/0e 0w/0e 778w/0e6w/0e 15w/0e861w/0e Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1) KernelbzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --- -- 2.6.11-rc2-mm1 15w/0e 0w/0e 306w/14e 6w/0e 18w/0e294w/0e 2.6.11-rc1-mm2 21w/0e 0w/0e 316w/9e6w/0e 22w/0e294w/0e 2.6.11-rc1-mm1 21w/0e 0w/0e 319w/0e6w/0e 23w/0e298w/0e 2.6.10-mm3 21w/0e 0w/0e 320w/0e6w/0e 23w/0e299w/0e 2.6.10-mm2 21w/0e 0w/0e 440w/0e6w/0e 23w/0e420w/0e 2.6.10-mm1 12w/0e 0w/0e 414w/0e6w/0e 17w/0e399w/0e Daily compiles (ia32): http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt Latest changes in Linus' bitkeeper tree: http://linux.bkbits.net:8080/linux-2.5 John - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Monday 24 January 2005 10:05 am, Martin Josefsson wrote: On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: ... - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. Is there a firewall on this machine? And if so, do you allow inbound icmp? It's behind a firewall; no firewall on that box though. The only difference between a working RC1 and non-working RC2 was the kernel. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
Linus, could you please put skb_copy_datagram back in place? It's not used
anymore in the kernel, but the vmnet module (in vmware) still uses this
interface to skb_copy_datagram_iovec.
Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
but I assume it's okay. I'll test it right after sending this mail and report
back here if something goes wrong.
Sytse
diff -ru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-01-25 01:27:00.0 +0100
+++ b/include/linux/skbuff.h2005-01-25 01:31:20.0 +0100
@@ -1086,6 +1086,8 @@
int noblock, int *err);
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
int size);
diff -ru a/net/core/datagram.c b/net/core/datagram.c
--- a/net/core/datagram.c 2005-01-25 01:27:01.0 +0100
+++ b/net/core/datagram.c 2005-01-25 01:31:20.0 +0100
@@ -199,6 +199,19 @@
kfree_skb(skb);
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, iov, size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
* @skb - buffer to copy
@@ -477,6 +490,7 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
EXPORT_SYMBOL(skb_recv_datagram);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On 25 Jan 05 at 1:41, Sytse Wielinga wrote: Linus, could you please put skb_copy_datagram back in place? It's not used anymore in the kernel, but the vmnet module (in vmware) still uses this interface to skb_copy_datagram_iovec. There is no reason for doing this. Just grab latest vmmon vmnet from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, and enjoy latest and greatest modules. Besides this one you'll get lot of other fixes and improvements for free ;-) Petr Vandrovec - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
On Tue, Jan 25, 2005 at 01:41:17AM +0100, Sytse Wielinga wrote: Linus, could you please put skb_copy_datagram back in place? It's not used anymore in the kernel, but the vmnet module (in vmware) still uses this interface to skb_copy_datagram_iovec. Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet, but I assume it's okay. I'll test it right after sending this mail and report back here if something goes wrong. Just fix vmware. Or upgrade to a fixed version that Petr mentioned already. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sun, Jan 23, 2005 at 10:11:45PM +0100, Magnus Määttä wrote: Hello Hi Magnus, It doesn't compile here, here's the error: CC net/sched/sch_generic.o net/sched/sch_generic.c: In function `qdisc_restart': net/sched/sch_generic.c:128: error: label `requeue' used but not defined make[2]: *** [net/sched/sch_generic.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 From .config: ... I wasn't able to reproduce your problem. Do you have any patches applied on top of 2.6.11-rc2 ? If not, please send: - your complete .config - the output of bash scripts/ver_linux TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... What ethereal shows me is roughly: - SMTP connect, initial handshake, ok (ACKed later) - Send two 1500 byte Ethernet packets - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
Hello On Saturday 22 January 2005 03.13, Linus Torvalds wrote: > Ok, trying to calm things down again for a 2.6.11 release. > > Tons of small cleanups, annotations and fixes here. Driver updates, > cpufreq, ppc, parisc, arm.. Pls check that I got it all. > > Linus > It doesn't compile here, here's the error: CC net/sched/sch_generic.o net/sched/sch_generic.c: In function `qdisc_restart': net/sched/sch_generic.c:128: error: label `requeue' used but not defined make[2]: *** [net/sched/sch_generic.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 >From .config: CONFIG_NET_KEY=m CONFIG_IP_MULTICAST=y CONFIG_NET_IPIP=m CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_IPCOMP=m CONFIG_IPV6_TUNNEL=m CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_IP_SCTP=m CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y CONFIG_NET_PKTGEN=m CONFIG_NET_POLL_CONTROLLER=y CONFIG_NET_ETHERNET=y CONFIG_NET_TULIP=y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
This patch worked. Or at least it built.
Thanks for the quick response.
sean
Martin Josefsson wrote:
Try this patch:
diff -X dontdiff.ny -urNp linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-22 15:23:45.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK 4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
This patch worked. Or at least it built.
Thanks for the quick response.
sean
Martin Josefsson wrote:
Try this patch:
diff -X dontdiff.ny -urNp linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-22 15:23:45.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK 4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
Hello On Saturday 22 January 2005 03.13, Linus Torvalds wrote: Ok, trying to calm things down again for a 2.6.11 release. Tons of small cleanups, annotations and fixes here. Driver updates, cpufreq, ppc, parisc, arm.. Pls check that I got it all. Linus It doesn't compile here, here's the error: CC net/sched/sch_generic.o net/sched/sch_generic.c: In function `qdisc_restart': net/sched/sch_generic.c:128: error: label `requeue' used but not defined make[2]: *** [net/sched/sch_generic.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 From .config: CONFIG_NET_KEY=m CONFIG_IP_MULTICAST=y CONFIG_NET_IPIP=m CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_IPCOMP=m CONFIG_IPV6_TUNNEL=m CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_IP_SCTP=m CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y CONFIG_NET_PKTGEN=m CONFIG_NET_POLL_CONTROLLER=y CONFIG_NET_ETHERNET=y CONFIG_NET_TULIP=y - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... What ethereal shows me is roughly: - SMTP connect, initial handshake, ok (ACKed later) - Send two 1500 byte Ethernet packets - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 18:54 -0500, sean wrote:
> I'm compiling with NAT, and get a different problem:
>
>LD net/ipv4/netfilter/built-in.o
> net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of
> `ip_nat_tftp_hook'
> net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here
> make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
> make[2]: *** [net/ipv4/netfilter] Error 2
Ok, another problem intriduced by the recent patches... sigh
Try this patch:
diff -X dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-22 15:23:45.00000 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
Martin Josefsson wrote: On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT> Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: "struct ip_conntrack" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: "enum ip_nat_manip_type" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) The problem is when compiling without NAT... The patch below should fix it, I can compile both with and without NAT now. I'm compiling with NAT, and get a different problem: LD net/ipv4/netfilter/built-in.o net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of `ip_nat_tftp_hook' net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005, Udo A. Steinberg wrote: > > Linus, please apply the following patch from Martin. Please go through Davem, he's quite responsive, but prefers things like this to be sent to the netdev mailing list too if it hasn't been there already (netdev@oss.sgi.com). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote:
MJ> On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
MJ> >
MJ> > Connection tracking does not compile...
MJ> The problem is when compiling without NAT...
MJ> The patch below should fix it, I can compile both with and without NAT
MJ> now.
Thanks, this fixes my problem, too.
Linus, please apply the following patch from Martin.
-Udo.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.00000 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, >status);
return test_bit(IPS_DST_NAT_DONE_BIT, >status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.000000000 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define CLUSTERIP_VERSION "0.6"
pgpjUUY1JDlce.pgp
Description: PGP signature
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 12:57 -0800, Udo A. Steinberg wrote: > On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote: > > MJ> On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: > MJ> > > MJ> > Connection tracking does not compile... > > MJ> The problem is when compiling without NAT... > MJ> The patch below should fix it, I can compile both with and without NAT > MJ> now. > > Thanks, this fixes my problem, too. Great. > Linus, please apply the following patch from Martin. It should trickle in to Linus tree through davem pretty soon I hope, together with some other bugfixes (fix for SNAT/DNAT not working at all on parisc and possibly other architectures) -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
> On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote:
>
> LT> Ok, trying to calm things down again for a 2.6.11 release.
>
> Connection tracking does not compile...
>
> CC net/ipv4/netfilter/ip_conntrack_standalone.o
> In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
> include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: "struct
> ip_conntrack" declared inside parameter list
> include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only
> this definition or declaration, which is probably not what you want
> include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: "enum
> ip_nat_manip_type" declared inside parameter list
> include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has
> incomplete type
> include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC'
> undeclared (first use in this function)
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared
> identifier is reported only once
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it
> appears in.)
The problem is when compiling without NAT...
The patch below should fix it, I can compile both with and without NAT
now.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, >status);
return test_bit(IPS_DST_NAT_DONE_BIT, >status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
Re: Linux 2.6.11-rc2
On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote:
LT Ok, trying to calm things down again for a 2.6.11 release.
Connection tracking does not compile...
CC net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: struct
ip_conntrack declared inside parameter list
include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only
this definition or declaration, which is probably not what you want
include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: enum
ip_nat_manip_type declared inside parameter list
include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has
incomplete type
include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC'
undeclared (first use in this function)
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared
identifier is reported only once
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it
appears in.)
The problem is when compiling without NAT...
The patch below should fix it, I can compile both with and without NAT
now.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, conntrack-status);
return test_bit(IPS_DST_NAT_DONE_BIT, conntrack-status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include linux/netfilter_ipv4/ip_tables.h
#include linux
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 12:57 -0800, Udo A. Steinberg wrote: On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote: MJ On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: MJ MJ Connection tracking does not compile... MJ The problem is when compiling without NAT... MJ The patch below should fix it, I can compile both with and without NAT MJ now. Thanks, this fixes my problem, too. Great. Linus, please apply the following patch from Martin. It should trickle in to Linus tree through davem pretty soon I hope, together with some other bugfixes (fix for SNAT/DNAT not working at all on parisc and possibly other architectures) -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote:
MJ On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
MJ
MJ Connection tracking does not compile...
MJ The problem is when compiling without NAT...
MJ The patch below should fix it, I can compile both with and without NAT
MJ now.
Thanks, this fixes my problem, too.
Linus, please apply the following patch from Martin.
-Udo.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, conntrack-status);
return test_bit(IPS_DST_NAT_DONE_BIT, conntrack-status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include linux/netfilter_ipv4/ip_tables.h
#include linux/netfilter_ipv4/ipt_CLUSTERIP.h
#include linux/netfilter_ipv4/ip_conntrack.h
+#include linux/netfilter_ipv4/lockhelp.h
#define CLUSTERIP_VERSION 0.6
pgpjUUY1JDlce.pgp
Description: PGP signature
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005, Udo A. Steinberg wrote: Linus, please apply the following patch from Martin. Please go through Davem, he's quite responsive, but prefers things like this to be sent to the netdev mailing list too if it hasn't been there already (netdev@oss.sgi.com). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
Martin Josefsson wrote: On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: struct ip_conntrack declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: enum ip_nat_manip_type declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) The problem is when compiling without NAT... The patch below should fix it, I can compile both with and without NAT now. I'm compiling with NAT, and get a different problem: LD net/ipv4/netfilter/built-in.o net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of `ip_nat_tftp_hook' net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 sean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 18:54 -0500, sean wrote:
I'm compiling with NAT, and get a different problem:
LD net/ipv4/netfilter/built-in.o
net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of
`ip_nat_tftp_hook'
net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here
make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
Ok, another problem intriduced by the recent patches... sigh
Try this patch:
diff -X dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-22 15:23:45.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT> Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: "struct ip_conntrack" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: "enum ip_nat_manip_type" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) -Udo. pgpvBTo55ykQ4.pgp Description: PGP signature
Linux 2.6.11-rc2
ructure changes to MPC85xx sub-arch from OCP to
platform_device
o ppc32: convert boards from using OCP to platform_device
o ppc32: Convert gianfar ethernet driver from using an OCP to
platform_device
Lennert Buytenhek:
o [NET]: Tone down the verbosity of diverter messages
Linas Vepstas:
o ppc64: PCI EEH documentation
Linus Torvalds:
o Handle two threads both trying to expand their stack simultaneously
o Make mm writelock testing less intrusive
o Make pipe buffer handling more generic
o scsi_ioctl: only warn about unknown opcodes if they are truly
unknown
o Revert "Don't busy-lock-loop in preemptable spinlocks" patch
o Remove old debugging tests
o Remove broken-as-designed "rwlock_is_locked()" macro
o Revert "x86_64/i386: increase command line size" patch
o ppc64: rwlock *_can_lock() primitives
o ia64: rwlock *_can_lock() primitives
o x86-64: rwlock *_can_lock() primitives
o Linux 2.6.11-rc2
Lonnie Mendez:
o USB cypress_m8: line setting bugfix, circular write buffer added,
misc. fixes
Lothar Wassmann:
o [ARM PATCH] 2395/1: __ioremap() miscalculates mapping size under
certain conditions
Luca Risolia:
o USB: SN9C10x driver updates
Maksim Krasnyanskiy:
o TUN/TAP driver packet queuing fixes and improvements
o Use random_ether_addr() to generate TAP MAC address
o [TUN] Add a missing dependency on enabling the crc32 libraries
Marc Singer:
o [ARM PATCH] 2394/1: Re: accepting responsibility for Sharp LH ports
Marcel Holtmann:
o [Bluetooth] Make some code of the core static
o [Bluetooth] Make another function static
o [Bluetooth] Make more code static
o [Bluetooth] Add module parameter for HCI_Reset
o [Bluetooth] Update socket option handling
o [Bluetooth] Add HIDP message parsing
o [Bluetooth] Remove casts in BCSP driver
o [Bluetooth] Add module parameter for ignoring a device
o [Bluetooth] Lock initializer cleanup
Marcelo Tosatti:
o do_brk() needs mmap_sem write-locked
Mark A. Greer:
o serial: MPSC driver
Markus Lidel:
o I2O: fix possible race condition and minor improvements
o I2O: printk cleanup and unnecessary code removal
Martin Schwidefsky:
o s390: 3270 console
Matt Mackall:
o random: whitespace doh
o random: entropy debugging improvements
o random: run-time configurable debugging
o random: periodicity detection fix
o random: add_input_randomness
Matt Porter:
o EMAC: fix ibm_emac autonegotiation result parsing
o allow rx of the maximum sized VLAN tagged packets
o Add netpoll support
o ppc32: fix PPC44x build
Matthew Dobson:
o Fix num_online_nodes() warning on NUMA-Q
Matthew Wilcox:
o sym2 version 2.1.18n
o Remove lasi700.h
o Misc zalon fixes
o Make compat_rt_sigtimedwait conform
o Generic IRQ support for PA-RISC
o PA-RISC: parisc_device diet
o PA-RISC defconfig updates
o PA-RISC: Misc Dino fixes
o PA-RISC: Misc HPUX emulation cleanups
o iomap for PA-RISC
o PA-RISC: More PDC procedures
o PA-RISC: Remove unused serial definitions
o PA-RISC: ptrace fix
o PA-RISC: Fix _syscallN wrappers
o PA-RISC: Sort out io accessors
o PA-RISC: Remove unused file
Michael Ellerman:
o ppc64: make HvLpEvent_unregisterHandler() work
o ppc64: make iseries_veth call flush_scheduled_work()
Michael S. Tsirkin:
o ioctl rework #2
o macros to detect existance of unlocked_ioctl and ioctl_compat
Mike Christie:
o export print_sense_internal
Mike Miller:
o cciss update to version 2.6.4
Milton D. Miller II:
o ppc64: Minimum hashtable size
Miquel van Smoorenburg:
o mark-page-accessed in filemap.c not quite right
Neil Horman:
o [ATALK]: Add ioctls to allow ifx txqueuelen sets/gets
Nicolas Pitre:
o [ARM PATCH] 2391/1: remove obsolete help text
o [ARM PATCH] 2204/1: bring {read|write}sw up to date with current
reality
o [ARM PATCH] 2423/2: more PXA2xx AC97 defines
Nigel Cunningham:
o swsusp: refrigerator cleanups
Olaf Kirch:
o [NET]: Fix CMSG_COMPAT_OK length check
o [NET]: Check for SOL_SOCKET in compat_sys_getsockopt
Oleg Nesterov:
o uninline mod_page_state(offset, delta)
Oliver Neukum:
o USB: CDC ACM module and Zoom 2985 modem
Olof Johansson:
o ppc64: iommu: avoid ISA io space on POWER3
Pablo Neira:
o [NETFILTER]: move ipt_error and ipt_standard to iptables.h
Paolo 'Blaisorblade' Giarrusso:
o uml: readd CONFIG_MAGIC_SYSRQ for UML
o uml: Commentary addition to recent SYSEMU fix
o uml: drop unused buffer_head.h header from hostfs
o uml: depend on !USERMODE in drivers/block/Kconfig and drop
arch/um/Kconfig_block
o uml: Makefile simplification and correction
o uml: fix some UML own initcall macros
o uml: refuse to run without skas if no tt mode in
o uml: for ubd cmdline param use colon as delimiter
o uml: allow free ubd flag ordering
o uml: move code from ubd_user to ubd_kern
o uml: fix and cleanup code in ubd_kern.c coming from ubd_user.c
o uml: add stack content to dumps
o
Linux 2.6.11-rc2
to
platform_device
o ppc32: convert boards from using OCP to platform_device
o ppc32: Convert gianfar ethernet driver from using an OCP to
platform_device
Lennert Buytenhek:
o [NET]: Tone down the verbosity of diverter messages
Linas Vepstas:
o ppc64: PCI EEH documentation
Linus Torvalds:
o Handle two threads both trying to expand their stack simultaneously
o Make mm writelock testing less intrusive
o Make pipe buffer handling more generic
o scsi_ioctl: only warn about unknown opcodes if they are truly
unknown
o Revert Don't busy-lock-loop in preemptable spinlocks patch
o Remove old debugging tests
o Remove broken-as-designed rwlock_is_locked() macro
o Revert x86_64/i386: increase command line size patch
o ppc64: rwlock *_can_lock() primitives
o ia64: rwlock *_can_lock() primitives
o x86-64: rwlock *_can_lock() primitives
o Linux 2.6.11-rc2
Lonnie Mendez:
o USB cypress_m8: line setting bugfix, circular write buffer added,
misc. fixes
Lothar Wassmann:
o [ARM PATCH] 2395/1: __ioremap() miscalculates mapping size under
certain conditions
Luca Risolia:
o USB: SN9C10x driver updates
Maksim Krasnyanskiy:
o TUN/TAP driver packet queuing fixes and improvements
o Use random_ether_addr() to generate TAP MAC address
o [TUN] Add a missing dependency on enabling the crc32 libraries
Marc Singer:
o [ARM PATCH] 2394/1: Re: accepting responsibility for Sharp LH ports
Marcel Holtmann:
o [Bluetooth] Make some code of the core static
o [Bluetooth] Make another function static
o [Bluetooth] Make more code static
o [Bluetooth] Add module parameter for HCI_Reset
o [Bluetooth] Update socket option handling
o [Bluetooth] Add HIDP message parsing
o [Bluetooth] Remove casts in BCSP driver
o [Bluetooth] Add module parameter for ignoring a device
o [Bluetooth] Lock initializer cleanup
Marcelo Tosatti:
o do_brk() needs mmap_sem write-locked
Mark A. Greer:
o serial: MPSC driver
Markus Lidel:
o I2O: fix possible race condition and minor improvements
o I2O: printk cleanup and unnecessary code removal
Martin Schwidefsky:
o s390: 3270 console
Matt Mackall:
o random: whitespace doh
o random: entropy debugging improvements
o random: run-time configurable debugging
o random: periodicity detection fix
o random: add_input_randomness
Matt Porter:
o EMAC: fix ibm_emac autonegotiation result parsing
o allow rx of the maximum sized VLAN tagged packets
o Add netpoll support
o ppc32: fix PPC44x build
Matthew Dobson:
o Fix num_online_nodes() warning on NUMA-Q
Matthew Wilcox:
o sym2 version 2.1.18n
o Remove lasi700.h
o Misc zalon fixes
o Make compat_rt_sigtimedwait conform
o Generic IRQ support for PA-RISC
o PA-RISC: parisc_device diet
o PA-RISC defconfig updates
o PA-RISC: Misc Dino fixes
o PA-RISC: Misc HPUX emulation cleanups
o iomap for PA-RISC
o PA-RISC: More PDC procedures
o PA-RISC: Remove unused serial definitions
o PA-RISC: ptrace fix
o PA-RISC: Fix _syscallN wrappers
o PA-RISC: Sort out io accessors
o PA-RISC: Remove unused file
Michael Ellerman:
o ppc64: make HvLpEvent_unregisterHandler() work
o ppc64: make iseries_veth call flush_scheduled_work()
Michael S. Tsirkin:
o ioctl rework #2
o macros to detect existance of unlocked_ioctl and ioctl_compat
Mike Christie:
o export print_sense_internal
Mike Miller:
o cciss update to version 2.6.4
Milton D. Miller II:
o ppc64: Minimum hashtable size
Miquel van Smoorenburg:
o mark-page-accessed in filemap.c not quite right
Neil Horman:
o [ATALK]: Add ioctls to allow ifx txqueuelen sets/gets
Nicolas Pitre:
o [ARM PATCH] 2391/1: remove obsolete help text
o [ARM PATCH] 2204/1: bring {read|write}sw up to date with current
reality
o [ARM PATCH] 2423/2: more PXA2xx AC97 defines
Nigel Cunningham:
o swsusp: refrigerator cleanups
Olaf Kirch:
o [NET]: Fix CMSG_COMPAT_OK length check
o [NET]: Check for SOL_SOCKET in compat_sys_getsockopt
Oleg Nesterov:
o uninline mod_page_state(offset, delta)
Oliver Neukum:
o USB: CDC ACM module and Zoom 2985 modem
Olof Johansson:
o ppc64: iommu: avoid ISA io space on POWER3
Pablo Neira:
o [NETFILTER]: move ipt_error and ipt_standard to iptables.h
Paolo 'Blaisorblade' Giarrusso:
o uml: readd CONFIG_MAGIC_SYSRQ for UML
o uml: Commentary addition to recent SYSEMU fix
o uml: drop unused buffer_head.h header from hostfs
o uml: depend on !USERMODE in drivers/block/Kconfig and drop
arch/um/Kconfig_block
o uml: Makefile simplification and correction
o uml: fix some UML own initcall macros
o uml: refuse to run without skas if no tt mode in
o uml: for ubd cmdline param use colon as delimiter
o uml: allow free ubd flag ordering
o uml: move code from ubd_user to ubd_kern
o uml: fix and cleanup code in ubd_kern.c coming from ubd_user.c
o uml: add stack content to dumps
o uml: update ld scripts to newer binutils
Patrick McHardy:
o [PKT_SCHED
Re: Linux 2.6.11-rc2
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: struct ip_conntrack declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: enum ip_nat_manip_type declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) -Udo. pgpvBTo55ykQ4.pgp Description: PGP signature
