NetBSD Problem Report #12790
Received: (qmail 16664 invoked from network); 30 Apr 2001 07:37:03 -0000
Message-Id: <200104300737.f3U7bhh13074@night-porter.duskware.de>
Date: Mon, 30 Apr 2001 09:37:43 +0200 (MEST)
From: Martin Husemann <martin@duskware.de>
Reply-To: martin@duskware.de
To: gnats-bugs@gnats.netbsd.org
Subject: path MTU discovery broken (net.inet.ip.mtudisc)
X-Send-Pr-Version: 3.95
>Number: 12790
>Category: kern
>Synopsis: path MTU discovery broken (net.inet.ip.mtudisc)
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Apr 30 07:38:01 +0000 2001
>Closed-Date: Sun May 26 16:06:45 +0000 2002
>Last-Modified: Fri Sep 05 13:44:01 +0000 2003
>Originator: Martin Husemann
>Release: 1.5U, cvs updated on April 28, 2001
>Organization:
>Environment:
System: NetBSD night-porter.duskware.de 1.5U NetBSD 1.5U (PORTER) #1: Sun Apr 29 11:55:20 MEST 2001 martin@night-porter.duskware.de:/usr/src/sys/arch/i386/compile/PORTER i386
Architecture: i386
Machine: i386
>Description:
Turning on path mtu discovery (sysctl -w net.inet.ip.mtudisc=1) breaks outgoing
connections if the path mut is less than the outgoing interfaces mtu (i.e. in
every case PMTU discovery makes sense at all).
See below for a tcpdump.
>How-To-Repeat:
I have an easy setup that triggers this bug reproduceably: my NAT/router
machine (nightfall) uses a PPPoE connection to the internet with an MTU of
1494. When I try to transfer something with scp to an outside machine,
the transfer stalls after a short time and later times out.
Here is a tcpdump of such a transfer until it stalls (didn't wait for the
timeout here).
tcpdump: listening on ep0
09:23:35.862212 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: S 1558831500:1558831500(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0> (DF)
09:23:36.084839 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: S 4289717678:4289717678(0) ack 1558831501 win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 759700 0>
09:23:36.085137 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . ack 1 win 17520 <nop,nop,timestamp 0 759700> (DF)
09:23:36.309145 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 1:53(52) ack 1 win 33580 <nop,nop,timestamp 759700 0>
09:23:36.312129 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 1:52(51) ack 53 win 17520 <nop,nop,timestamp 0 759700> (DF)
09:23:36.541785 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 53:377(324) ack 52 win 33580 <nop,nop,timestamp 759701 0>
09:23:36.602678 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 52:224(172) ack 377 win 17520 <nop,nop,timestamp 1 759701> (DF)
09:23:37.836362 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 52:224(172) ack 377 win 17520 <nop,nop,timestamp 3 759701> (DF)
09:23:37.948056 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 53:377(324) ack 52 win 33580 <nop,nop,timestamp 759703 0>
09:23:37.948481 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . ack 377 win 17520 <nop,nop,timestamp 4 759701> (DF)
09:23:38.078822 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 224 win 33580 <nop,nop,timestamp 759704 1>
09:23:38.369818 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 377:389(12) ack 224 win 33580 <nop,nop,timestamp 759704 1>
09:23:38.370822 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 224:244(20) ack 389 win 17520 <nop,nop,timestamp 5 759704> (DF)
09:23:38.644848 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 244 win 33580 <nop,nop,timestamp 759705 5>
09:23:38.780611 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 389:401(12) ack 244 win 33580 <nop,nop,timestamp 759705 5>
09:23:38.782466 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 244:384(140) ack 401 win 17520 <nop,nop,timestamp 5 759705> (DF)
09:23:39.043818 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 384 win 33580 <nop,nop,timestamp 759706 5>
09:23:39.063681 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 401:541(140) ack 384 win 33580 <nop,nop,timestamp 759706 5>
09:23:39.135656 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . ack 541 win 17520 <nop,nop,timestamp 6 759706> (DF)
09:23:39.235837 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 384:412(28) ack 541 win 17520 <nop,nop,timestamp 6 759706> (DF)
09:23:39.458161 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 541:585(44) ack 412 win 33580 <nop,nop,timestamp 759707 6>
09:23:39.536770 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . ack 585 win 17520 <nop,nop,timestamp 7 759707> (DF)
09:23:39.756856 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 585:597(12) ack 412 win 33580 <nop,nop,timestamp 759707 6>
09:23:39.758008 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 412:440(28) ack 597 win 17520 <nop,nop,timestamp 7 759707> (DF) [tos 0x8]
09:23:40.044460 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 440 win 33580 <nop,nop,timestamp 759708 7> [tos 0x8]
09:23:40.214381 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 597:617(20) ack 440 win 33580 <nop,nop,timestamp 759708 7> [tos 0x8]
09:23:40.216371 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: P 440:484(44) ack 617 win 17520 <nop,nop,timestamp 8 759708> (DF) [tos 0x8]
09:23:40.444599 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 484 win 33580 <nop,nop,timestamp 759709 8> [tos 0x8]
09:23:40.504336 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: P 617:637(20) ack 484 win 33580 <nop,nop,timestamp 759709 8> [tos 0x8]
09:23:40.515641 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1932(1448) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
09:23:40.516149 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 1932:3380(1448) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
09:23:40.516945 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
09:23:40.517548 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
09:23:40.518090 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
09:23:40.518590 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
09:23:40.518816 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 1926:1978(52) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
09:23:40.744466 ftp.netbsd.org.ssh > setting-sun.duskware.de.65530: . ack 484 win 33580 <nop,nop,timestamp 759709 8> [tos 0x8]
09:23:41.835021 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 11 759709> (DF) [tos 0x8]
09:23:43.834062 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 15 759709> (DF) [tos 0x8]
09:23:47.832156 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 23 759709> (DF) [tos 0x8]
09:23:55.828357 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 39 759709> (DF) [tos 0x8]
09:24:11.820729 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1932(1448) ack 637 win 17520 <nop,nop,timestamp 71 759709> (DF) [tos 0x8]
09:24:11.821475 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
09:24:11.822431 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 72 759709> (DF) [tos 0x8]
>Fix:
Only a workaround:
Leaving net.inet.ip.mtudisc at it's default value (0) prevents the problem.
>Release-Note:
>Audit-Trail:
From: itojun@iijlab.net
To: martin@duskware.de
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Mon, 30 Apr 2001 16:50:25 +0900
>>How-To-Repeat:
>
>I have an easy setup that triggers this bug reproduceably: my NAT/router
>machine (nightfall) uses a PPPoE connection to the internet with an MTU of
>1494. When I try to transfer something with scp to an outside machine,
>the transfer stalls after a short time and later times out.
>
>Here is a tcpdump of such a transfer until it stalls (didn't wait for the
>timeout here).
could you run tcpdump on the other end as well?
also, please give "-vvv" to tcpdump, to make it more verbose.
>09:23:40.515641 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1932(1448) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
>09:23:40.516149 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 1932:3380(1448) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
>09:23:40.516945 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
>09:23:40.517548 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
>09:23:40.518090 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
>09:23:40.518590 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 484:1926(1442) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
>09:23:40.518816 setting-sun.duskware.de.65530 > ftp.netbsd.org.ssh: . 1926:1978(52) ack 637 win 17520 <nop,nop,timestamp 9 759709> (DF) [tos 0x8]
(snip)
>09:24:11.821475 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494)
here, netbsd box reacted to icmp message, however, the packet did not
go through? why?
itojun
From: Martin Husemann <martin@duskware.de>
To: itojun@iijlab.net
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Mon, 30 Apr 2001 11:15:42 +0200 (MEST)
> could you run tcpdump on the other end as well?
> also, please give "-vvv" to tcpdump, to make it more verbose.
Sure. I did "tcpdump -i XXX -l -s 2000 -vvv icmp or host ftp.netbsd.org" this
time.
> here, netbsd box reacted to icmp message, however, the packet did not
> go through? why?
Because of the bug in question, I suppose. It is not lost (see below).
Here is a new log from the nat machine:
11:08:15.038656 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: S [tcp sum ok] 2050503341:2050503341(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) (ttl 64, id 64408)
11:08:15.261794 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: S [tcp sum ok] 3402710065:3402710065(0) ack 2050503342 win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 772258 0> (ttl 50, id 43545)
11:08:15.262101 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1:1(0) ack 1 win 17520 <nop,nop,timestamp 0 772258> (DF) (ttl 64, id 64410)
11:08:15.485819 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 1:53(52) ack 1 win 33580 <nop,nop,timestamp 772259 0> (ttl 50, id 43688)
11:08:15.488887 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 1:52(51) ack 53 win 17520 <nop,nop,timestamp 1 772259> (DF) (ttl 64, id 64411)
11:08:16.479689 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 1:52(51) ack 53 win 17520 <nop,nop,timestamp 2 772259> (DF) (ttl 64, id 64415)
11:08:16.704819 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 53:377(324) ack 52 win 33580 <nop,nop,timestamp 772261 1> (ttl 50, id 44316)
11:08:16.705972 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 377:377(0) ack 52 win 33580 <nop,nop,timestamp 772261 1> (ttl 50, id 44327)
11:08:16.734945 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 52:224(172) ack 377 win 17520 <nop,nop,timestamp 3 772261> (DF) (ttl 64, id 64417)
11:08:17.083536 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 377:377(0) ack 224 win 33580 <nop,nop,timestamp 772262 3> (ttl 50, id 44568)
11:08:17.248495 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 377:389(12) ack 224 win 33580 <nop,nop,timestamp 772262 3> (ttl 50, id 44661)
11:08:17.249483 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 224:244(20) ack 389 win 17520 <nop,nop,timestamp 4 772262> (DF) (ttl 64, id 64418)
11:08:17.482801 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 389:389(0) ack 244 win 33580 <nop,nop,timestamp 772263 4> (ttl 50, id 44797)
11:08:17.534474 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 389:401(12) ack 244 win 33580 <nop,nop,timestamp 772263 4> (ttl 50, id 44824)
11:08:17.536659 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 244:384(140) ack 401 win 17520 <nop,nop,timestamp 5 772263> (DF) (ttl 64, id 64419)
11:08:17.846356 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 401:541(140) ack 384 win 33580 <nop,nop,timestamp 772264 5> (ttl 50, id 44984)
11:08:17.878997 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 384:384(0) ack 541 win 17520 <nop,nop,timestamp 5 772264> (DF) (ttl 64, id 64422)
11:08:18.032370 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 384:412(28) ack 541 win 17520 <nop,nop,timestamp 6 772264> (DF) (ttl 64, id 64423)
11:08:18.253540 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 541:585(44) ack 412 win 33580 <nop,nop,timestamp 772264 6> (ttl 50, id 45221)
11:08:18.278748 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 412:412(0) ack 585 win 17520 <nop,nop,timestamp 6 772264> (DF) (ttl 64, id 64424)
11:08:18.498536 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 585:597(12) ack 412 win 33580 <nop,nop,timestamp 772265 6> (ttl 50, id 45364)
11:08:18.499316 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 412:432(20) ack 597 win 17520 <nop,nop,timestamp 7 772265> (DF) (ttl 64, id 64425)
11:08:18.722712 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 597:609(12) ack 432 win 33580 <nop,nop,timestamp 772265 7> (ttl 50, id 45488)
11:08:18.734705 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 432:460(28) ack 609 win 17520 <nop,nop,timestamp 7 772265> (DF) [tos 0x8] (ttl 64, id 64427)
11:08:19.082839 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 609:609(0) ack 460 win 33580 <nop,nop,timestamp 772266 7> [tos 0x8] (ttl 50, id 45712)
11:08:19.215769 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 609:629(20) ack 460 win 33580 <nop,nop,timestamp 772266 7> [tos 0x8] (ttl 50, id 45788)
11:08:19.218651 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 460:504(44) ack 629 win 17520 <nop,nop,timestamp 8 772266> (DF) [tos 0x8] (ttl 64, id 64428)
11:08:19.483052 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 629:629(0) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 45957)
11:08:19.515693 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 629:649(20) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 45979)
11:08:19.531967 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1952(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64430)
11:08:19.532508 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1952:3400(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64431)
11:08:19.533301 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494) (ttl 255, id 11862)
11:08:19.533900 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494) (ttl 255, id 11863)
11:08:19.534549 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64432)
11:08:19.535042 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64433)
11:08:19.535250 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1946:1998(52) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64434)
11:08:19.759685 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 649:649(0) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 46118)
11:08:21.477933 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 12 772267> (DF) [tos 0x8] (ttl 64, id 64443)
11:08:25.476013 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 20 772267> (DF) [tos 0x8] (ttl 64, id 64451)
11:08:33.472200 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 36 772267> (DF) [tos 0x8] (ttl 64, id 64463)
11:08:49.464582 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 68 772267> (DF) [tos 0x8] (ttl 64, id 64487)
And this is from the client trying to do the "scp":
11:08:14.976499 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: S [tcp sum ok] 2050503341:2050503341(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) (ttl 64, id 64408)
11:08:15.206397 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: S [tcp sum ok] 3402710065:3402710065(0) ack 2050503342 win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 772258 0> (ttl 50, id 43545)
11:08:15.206397 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1:1(0) ack 1 win 17520 <nop,nop,timestamp 0 772258> (DF) (ttl 64, id 64410)
11:08:15.426299 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 1:53(52) ack 1 win 33580 <nop,nop,timestamp 772259 0> (ttl 50, id 43688)
11:08:15.426299 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 1:52(51) ack 53 win 17520 <nop,nop,timestamp 1 772259> (DF) (ttl 64, id 64411)
11:08:16.425856 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 1:52(51) ack 53 win 17520 <nop,nop,timestamp 2 772259> (DF) (ttl 64, id 64415)
11:08:16.645759 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 53:377(324) ack 52 win 33580 <nop,nop,timestamp 772261 1> (ttl 50, id 44316)
11:08:16.645759 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 377:377(0) ack 52 win 33580 <nop,nop,timestamp 772261 1> (ttl 50, id 44327)
11:08:16.675746 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 52:224(172) ack 377 win 17520 <nop,nop,timestamp 3 772261> (DF) (ttl 64, id 64417)
11:08:17.025591 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 377:377(0) ack 224 win 33580 <nop,nop,timestamp 772262 3> (ttl 50, id 44568)
11:08:17.185520 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 377:389(12) ack 224 win 33580 <nop,nop,timestamp 772262 3> (ttl 50, id 44661)
11:08:17.195515 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 224:244(20) ack 389 win 17520 <nop,nop,timestamp 4 772262> (DF) (ttl 64, id 64418)
11:08:17.425413 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 389:389(0) ack 244 win 33580 <nop,nop,timestamp 772263 4> (ttl 50, id 44797)
11:08:17.475391 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 389:401(12) ack 244 win 33580 <nop,nop,timestamp 772263 4> (ttl 50, id 44824)
11:08:17.475391 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 244:384(140) ack 401 win 17520 <nop,nop,timestamp 5 772263> (DF) (ttl 64, id 64419)
11:08:17.785254 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 401:541(140) ack 384 win 33580 <nop,nop,timestamp 772264 5> (ttl 50, id 44984)
11:08:17.825236 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 384:384(0) ack 541 win 17520 <nop,nop,timestamp 5 772264> (DF) (ttl 64, id 64422)
11:08:17.975170 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 384:412(28) ack 541 win 17520 <nop,nop,timestamp 6 772264> (DF) (ttl 64, id 64423)
11:08:18.195072 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 541:585(44) ack 412 win 33580 <nop,nop,timestamp 772264 6> (ttl 50, id 45221)
11:08:18.225059 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 412:412(0) ack 585 win 17520 <nop,nop,timestamp 6 772264> (DF) (ttl 64, id 64424)
11:08:18.444961 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 585:597(12) ack 412 win 33580 <nop,nop,timestamp 772265 6> (ttl 50, id 45364)
11:08:18.444961 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 412:432(20) ack 597 win 17520 <nop,nop,timestamp 7 772265> (DF) (ttl 64, id 64425)
11:08:18.664864 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 597:609(12) ack 432 win 33580 <nop,nop,timestamp 772265 7> (ttl 50, id 45488)
11:08:18.674860 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 432:460(28) ack 609 win 17520 <nop,nop,timestamp 7 772265> (DF) [tos 0x8] (ttl 64, id 64427)
11:08:19.024704 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 609:609(0) ack 460 win 33580 <nop,nop,timestamp 772266 7> [tos 0x8] (ttl 50, id 45712)
11:08:19.154647 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 609:629(20) ack 460 win 33580 <nop,nop,timestamp 772266 7> [tos 0x8] (ttl 50, id 45788)
11:08:19.164642 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: P [tcp sum ok] 460:504(44) ack 629 win 17520 <nop,nop,timestamp 8 772266> (DF) [tos 0x8] (ttl 64, id 64428)
11:08:19.424527 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 629:629(0) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 45957)
11:08:19.454514 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: P [tcp sum ok] 629:649(20) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 45979)
11:08:19.474505 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1952(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64430)
11:08:19.474505 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1952:3400(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64431)
11:08:19.474505 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494) (ttl 255, id 11862)
11:08:19.474505 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64432)
11:08:19.474505 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494) (ttl 255, id 11863)
11:08:19.474505 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64433)
11:08:19.474505 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1946:1998(52) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64434)
11:08:19.704403 ftp.netbsd.org.ssh > setting-sun.duskware.de.65526: . [tcp sum ok] 649:649(0) ack 504 win 33580 <nop,nop,timestamp 772267 8> [tos 0x8] (ttl 50, id 46118)
11:08:21.423641 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 12 772267> (DF) [tos 0x8] (ttl 64, id 64443)
11:08:25.421868 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 20 772267> (DF) [tos 0x8] (ttl 64, id 64451)
11:08:33.418322 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 36 772267> (DF) [tos 0x8] (ttl 64, id 64463)
11:08:49.411224 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 68 772267> (DF) [tos 0x8] (ttl 64, id 64487)
Martin
From: Martin Husemann <martin@duskware.de>
To: itojun@iijlab.net
Cc:
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Mon, 30 Apr 2001 11:31:19 +0200 (MEST)
BTW, Jason mentioned (on icb) the bug would be (more or less) known and
probably be related to route.c rev. 1.25/1.27. Some dubious assignements to
rmx_mtu, IIRC.
Martin
From: itojun@iijlab.net
To: Martin Husemann <martin@duskware.de>
Cc:
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Tue, 01 May 2001 00:29:25 +0900
>BTW, Jason mentioned (on icb) the bug would be (more or less) known and
>probably be related to route.c rev. 1.25/1.27. Some dubious assignements to
>rmx_mtu, IIRC.
do you have results from "netstat -rn" during the tests?
we can get rmx_mtu from the result and check if they are correct.
itojun
From: Martin Husemann <martin@duskware.de>
To: itojun@iijlab.net
Cc:
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Mon, 30 Apr 2001 17:36:32 +0200 (MEST)
> do you have results from "netstat -rn" during the tests?
> we can get rmx_mtu from the result and check if they are correct.
This is in the stalled state (i.e. after the "need frag" has been received)
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.150.10 UGS 0 379 1500 hme0
0.0.0.1 0.0.0.0 UH 0 0 1500 isp0
127 127.0.0.1 UGRS 0 0 33192 lo0
127.0.0.1 127.0.0.1 UH 2 2 33192 lo0
192.168.150 link#1 UC 2 0 1500 hme0
192.168.150.7 00:00:c0:87:5f:f2 UHLc 3 22554 1500 hme0
192.168.150.10 00:10:4b:24:be:a8 UHLc 4 169 1500 hme0
192.168.199 link#2 UC 0 0 1500 vr0
204.152.184.75 192.168.150.10 UGHD 1 6 1494 hme0
Funny, so it is noting the right MTU, but still sending bigger packets?
Martin
From: itojun@iijlab.net
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Tue, 01 May 2001 00:48:59 +0900
please keep emails cc'ed to gnats-bugs@gnats.netbsd.org,
otherwise the email exchange won't appear on the database.
>> do you have results from "netstat -rn" during the tests?
>> we can get rmx_mtu from the result and check if they are correct.
>This is in the stalled state (i.e. after the "need frag" has been received)
>Routing tables
>Internet:
>Destination Gateway Flags Refs Use Mtu Interface
>default 192.168.150.10 UGS 0 379 1500 hme0
>0.0.0.1 0.0.0.0 UH 0 0 1500 isp0
>127 127.0.0.1 UGRS 0 0 33192 lo0
>127.0.0.1 127.0.0.1 UH 2 2 33192 lo0
>192.168.150 link#1 UC 2 0 1500 hme0
>192.168.150.7 00:00:c0:87:5f:f2 UHLc 3 22554 1500 hme0
>192.168.150.10 00:10:4b:24:be:a8 UHLc 4 169 1500 hme0
>192.168.199 link#2 UC 0 0 1500 vr0
>204.152.184.75 192.168.150.10 UGHD 1 6 1494 hme0
>Funny, so it is noting the right MTU, but still sending bigger packets?
setting-sun have sent a TCP segment that is sized 1500.
ip header: 20 bytes
tcp header: 20 bytes
tcp option: 12 bytes (2 nop, 1 timestamp)
body: 1448 bytes
11:08:19.531967 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1952(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64430)
11:08:19.532508 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 1952:3400(1448) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64431)
nightfall tells setting-sun that the path MTU is 1494, and
setting-sun leant about it. on the routing table it is apparent
that setting-sun leant this.
11:08:19.533900 nightfall.duskware.de > setting-sun.duskware.de: icmp: ftp.netbsd.org unreachable - need to frag (mtu 1494) (ttl 255, id 11863)
now, setting-sun have reorganized the TCP segment and sent it again
with different size. the packet is 1494 bytes.
ip header: 20 bytes
tcp header: 20 bytes
tcp option: 12 bytes (2 nop, 1 timestamp)
body: 1442 bytes
11:08:19.534549 setting-sun.duskware.de.65526 > ftp.netbsd.org.ssh: . [tcp sum ok] 504:1946(1442) ack 649 win 17520 <nop,nop,timestamp 9 772267> (DF) [tos 0x8] (ttl 64, id 64432)
the packet should go through, however it does not.
so, i suspect that there's some wrongly-configured router that drops
all icmp4 messages. i believe netbsd box (setting-sun) is not to be
blamed.
itojun
From: Martin Husemann <martin@duskware.de>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Mon, 30 Apr 2001 18:46:11 +0200 (MEST)
> so, i suspect that there's some wrongly-configured router that drops
> all icmp4 messages. i believe netbsd box (setting-sun) is not to be
> blamed.
Ouch, you are right. And to make realy sure the other NetBSD box (night-fall,
the NAT & router) isn't to blame either, I did the same test from there -
same results.
So it is all "normal" internet lossage, and this PR should be closed? Do we
have blackhole discovery at all?
Thanks for analyzing this!
Martin
From: itojun@iijlab.net
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Tue, 01 May 2001 01:54:21 +0900
>> so, i suspect that there's some wrongly-configured router that drops
>> all icmp4 messages. i believe netbsd box (setting-sun) is not to be
>> blamed.
>
>Ouch, you are right. And to make realy sure the other NetBSD box (night-fall,
>the NAT & router) isn't to blame either, I did the same test from there -
>same results.
>
>So it is all "normal" internet lossage, and this PR should be closed? Do we
>have blackhole discovery at all?
just fyi:
the problem is very common for DSL services in Japan. local phone
line provider uses L2TP for wide area DSL/ISDN services, and their
MTU is lower than 1500. there are way too many sites which
configures web server to run path mtu discovery, and configures
router to drop all icmp (router A).
now, when we pull data off from www.foo.com,
- www.foo.com tries to run path mtu discovery
- big packet from www.foo.com dropped at router B
- "too big" icmp sent by router B to www.foo.com,
- the icmp message dropped at router A,
- www.foo.com locks up.
www.foo.com, uses path mtu discovery
| 1500
bad router A drops all icmp
| 1500
router B
| 1400
router C
| 1500
my machine
here are our TODOs:
when our side is sending data (like the tcpdump you have presented),
we should provide some blackhole discovery. i'll try to look at this
direction soon (not sure if it makes it to 1.5.1).
if the other side is sending data (like pulling data off from
www.foo.com) there's almost nothing we can do. we should educate
random admins to do the following:
- if you filter icmp, turn off path mtu discovery on www.foo.com
- if you turn on path mtu discovery on www.foo.com, do not filter icmp
itojun
State-Changed-From-To: open->feedback
State-Changed-By: itojun
State-Changed-When: Mon Apr 30 17:10:05 PDT 2001
State-Changed-Why:
netbsd was not wrong, however, we should implement a better blackhole
detection
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
To: Martin Husemann <martin@duskware.de>
Cc:
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Tue, 01 May 2001 17:43:02 +0900
>>> when our side is sending data (like the tcpdump you have presented),
>>> we should provide some blackhole discovery. i'll try to look at this
>>> direction soon (not sure if it makes it to 1.5.1).
>>Great!
> but i got too many TODOs you know :-)
the patch is for netbsd-current (1.5U). it tries to turn off
path MTU discovery if the peer seems to be losing (more than 2
retransmits). you need to recompile usr.bin/netstat too.
itojun
Index: tcp_output.c
===================================================================
RCS file: /cvsroot/syssrc/sys/netinet/tcp_output.c,v
retrieving revision 1.65
diff -u -r1.65 tcp_output.c
--- tcp_output.c 2001/04/03 06:14:31 1.65
+++ tcp_output.c 2001/05/01 08:41:37
@@ -222,12 +222,12 @@
ifp = rt->rt_ifp;
size = tcp_mssdflt;
- if (rt->rt_rmx.rmx_mtu != 0)
+ if (tp->t_mtudisc && rt->rt_rmx.rmx_mtu != 0) /*XXX*/
size = rt->rt_rmx.rmx_mtu - iphlen - sizeof(struct tcphdr);
else if (ifp->if_flags & IFF_LOOPBACK)
size = ifp->if_mtu - iphlen - sizeof(struct tcphdr);
#ifdef INET
- else if (inp && ip_mtudisc)
+ else if (inp && tp->t_mtudisc)
size = ifp->if_mtu - iphlen - sizeof(struct tcphdr);
else if (inp && in_localaddr(inp->inp_faddr))
size = ifp->if_mtu - iphlen - sizeof(struct tcphdr);
@@ -239,7 +239,7 @@
/* mapped addr case */
struct in_addr d;
bcopy(&in6p->in6p_faddr.s6_addr32[3], &d, sizeof(d));
- if (ip_mtudisc || in_localaddr(d))
+ if (tp->t_mtudisc || in_localaddr(d))
size = ifp->if_mtu - iphlen - sizeof(struct tcphdr);
} else
#endif
@@ -248,7 +248,8 @@
* for IPv6, path MTU discovery is always turned on,
* or the node must use packet size <= 1280.
*/
- size = ifp->if_mtu - iphlen - sizeof(struct tcphdr);
+ size = tp->t_mtudisc ? ifp->if_mtu : IPV6_MMTU;
+ size -= (iphlen + sizeof(struct tcphdr);
}
}
#endif
@@ -1022,7 +1023,7 @@
else
opts = NULL;
error = ip_output(m, opts, ro,
- (ip_mtudisc ? IP_MTUDISC : 0) |
+ (tp->t_mtudisc ? IP_MTUDISC : 0) |
(so->so_options & SO_DONTROUTE),
0);
break;
Index: tcp_subr.c
===================================================================
RCS file: /cvsroot/syssrc/sys/netinet/tcp_subr.c,v
retrieving revision 1.109
diff -u -r1.109 tcp_subr.c
--- tcp_subr.c 2001/03/21 03:35:11 1.109
+++ tcp_subr.c 2001/05/01 08:41:38
@@ -709,7 +709,7 @@
#ifdef INET
case AF_INET:
error = ip_output(m, NULL, ro,
- (ip_mtudisc ? IP_MTUDISC : 0),
+ ((tp && tp->t_mtudisc) ? IP_MTUDISC : 0),
NULL);
break;
#endif
@@ -775,10 +775,13 @@
switch (family) {
case PF_INET:
tp->t_inpcb = (struct inpcb *)aux;
+ tp->t_mtudisc = ip_mtudisc;
break;
#ifdef INET6
case PF_INET6:
tp->t_in6pcb = (struct in6pcb *)aux;
+ /* for IPv6, always try to run path MTU discovery */
+ tp->t_mtudisc = 1;
break;
#endif
}
@@ -1246,7 +1249,7 @@
notify = tcp_quench;
else if (PRC_IS_REDIRECT(cmd))
notify = in_rtchange, ip = 0;
- else if (cmd == PRC_MSGSIZE && ip_mtudisc && ip && ip->ip_v == 4) {
+ else if (cmd == PRC_MSGSIZE && ip && ip->ip_v == 4) {
/*
* Check to see if we have a valid TCP connection
* corresponding to the address in the ICMP message
Index: tcp_timer.c
===================================================================
RCS file: /cvsroot/syssrc/sys/netinet/tcp_timer.c,v
retrieving revision 1.48
diff -u -r1.48 tcp_timer.c
--- tcp_timer.c 2000/10/19 20:23:00 1.48
+++ tcp_timer.c 2001/05/01 08:41:38
@@ -340,7 +340,7 @@
TCPT_RANGESET(tp->t_rxtcur, rto * tcp_backoff[tp->t_rxtshift],
tp->t_rttmin, TCPTV_REXMTMAX);
TCP_TIMER_ARM(tp, TCPT_REXMT, tp->t_rxtcur);
-#if 0
+
/*
* If we are losing and we are trying path MTU discovery,
* try turning it off. This will avoid black holes in
@@ -349,21 +349,23 @@
* lots more sophisticated searching to find the right
* value here...
*/
- if (ip_mtudisc && tp->t_rxtshift > TCP_MAXRXTSHIFT / 6) {
- struct rtentry *rt = NULL;
+ if (tp->t_mtudisc && tp->t_rxtshift > TCP_MAXRXTSHIFT / 6) {
+ tcpstat.tcps_pmtublackhole++;
#ifdef INET
+ /* try turning pmtud off */
if (tp->t_inpcb)
- rt = in_pcbrtentry(tp->t_inpcb);
+ tp->t_mtudisc = 0;
#endif
#ifdef INET6
+ /* try using IPv6 minimum MTU */
if (tp->t_in6pcb)
- rt = in6_pcbrtentry(tp->t_in6pcb);
+ tp->t_mtudisc = 0;
#endif
- /* XXX: Black hole recovery code goes here */
+ /* XXX: more sophisticated Black hole recovery code? */
}
-#endif
+
/*
* If losing, let the lower level know and try for
* a better route. Also, if we backed off this far,
Index: tcp_var.h
===================================================================
RCS file: /cvsroot/syssrc/sys/netinet/tcp_var.h,v
retrieving revision 1.79
diff -u -r1.79 tcp_var.h
--- tcp_var.h 2001/04/13 23:30:24 1.79
+++ tcp_var.h 2001/05/01 08:41:39
@@ -226,6 +226,9 @@
/* SACK stuff */
struct ipqehead timeq; /* time sequenced queue (for SACK) */
+/* path MTU discovery blackhole detection */
+ int t_mtudisc; /* perform mtudisc for this tcb */
+
/* pointer for syn cache entries*/
LIST_HEAD(, syn_cache) t_sc; /* list of entries by this tcb */
};
@@ -462,6 +465,7 @@
u_quad_t tcps_persistdrops; /* connections dropped in persist */
u_quad_t tcps_connsdrained; /* connections drained due to memory
shortage */
+ u_quad_t tcps_pmtublackhole; /* PMTUD blackhole detected */
u_quad_t tcps_sndtotal; /* total packets sent */
u_quad_t tcps_sndpack; /* data packets sent */
From: Martin Husemann <martin@duskware.de>
To: itojun@iijlab.net
Cc: gnats-bugs@NetBSD.ORG
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Thu, 3 May 2001 21:54:52 +0200 (MEST)
Sorry, the patch did not work for me (transfer stalls, discovery seems not to
be turned off). Unfortunately I have no time to examine things further right
now, will do so later.
Martin
From: itojun@iijlab.net
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.ORG
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc)
Date: Fri, 04 May 2001 12:35:01 +0900
>Sorry, the patch did not work for me (transfer stalls, discovery seems not to
>be turned off). Unfortunately I have no time to examine things further right
>now, will do so later.
if you could get a tcpdump trace, it will be really helpful.
we need to wait a couple of retransmissions of segments, till we detect
PMTUD lossage.
itojun
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.ORG
Cc:
Subject: Re: kern/12790: path MTU discovery broken (net.inet.ip.mtudisc) (fwd)
Date: Sun, 20 May 2001 14:49:56 +0200 (MEST)
Sorry, just noted that I did not Cc: gnats on the final answer; here it is
again:
Ouch, got the ofwboot syntax wrong and booted another kernel without that
patch when trying ;-)
Sorry: it actually *does* work for me.
The "scp" stalls for a short time, then continues and finishes successfully.
Great!
Martin
State-Changed-From-To: feedback->closed
State-Changed-By: fair
State-Changed-When: Fri Jan 4 20:01:14 PST 2002
State-Changed-Why:
submitter reports that the work-around for blackhole detection works
for him, so this PR is resolved...
State-Changed-From-To: closed->open
State-Changed-By: martin
State-Changed-When: Sat Jan 5 01:56:54 PST 2002
State-Changed-Why:
While the patch in the PR worked for me, it is not yet commited to -current.
Someone please sanity check it and then commit it!
State-Changed-From-To: open->closed
State-Changed-By: itojun
State-Changed-When: Sun May 26 09:06:21 PDT 2002
State-Changed-Why:
finally committed. sorry for leaving it in PR list for a long time
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: pr/12790 CVS commit: [netbsd-1-6] src/usr.bin/netstat
Date: Fri, 5 Sep 2003 13:42:23 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Sep 5 13:42:23 UTC 2003
Modified Files:
src/usr.bin/netstat [netbsd-1-6]: inet.c
Log Message:
Pull up revision 1.52 (requested by tls in ticket #1445):
path MTU discovery blackhole detection.
PR 12790 (sorry for not committing it for a long time)
To generate a diff of this commit:
cvs rdiff -r1.51 -r1.51.2.1 src/usr.bin/netstat/inet.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: pr/12790 CVS commit: [netbsd-1-6] src/sys/netinet
Date: Fri, 5 Sep 2003 13:42:32 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Sep 5 13:42:32 UTC 2003
Modified Files:
src/sys/netinet [netbsd-1-6]: tcp_subr.c
Log Message:
Pull up revision 1.128 (requested by tls in ticket #1445):
path MTU discovery blackhole detection.
PR 12790 (sorry for not committing it for a long time)
To generate a diff of this commit:
cvs rdiff -r1.127.4.1 -r1.127.4.2 src/sys/netinet/tcp_subr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: pr/12790 CVS commit: [netbsd-1-6] src/sys/netinet
Date: Fri, 5 Sep 2003 13:42:40 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Sep 5 13:42:40 UTC 2003
Modified Files:
src/sys/netinet [netbsd-1-6]: tcp_output.c
Log Message:
Pull up revision 1.80 (requested by tls in ticket #1445):
path MTU discovery blackhole detection.
PR 12790 (sorry for not committing it for a long time)
To generate a diff of this commit:
cvs rdiff -r1.79.4.3 -r1.79.4.4 src/sys/netinet/tcp_output.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: pr/12790 CVS commit: [netbsd-1-6] src/sys/netinet
Date: Fri, 5 Sep 2003 13:42:46 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Sep 5 13:42:46 UTC 2003
Modified Files:
src/sys/netinet [netbsd-1-6]: tcp_var.h
Log Message:
Pull up revision 1.91 (requested by tls in ticket #1445):
path MTU discovery blackhole detection.
PR 12790 (sorry for not committing it for a long time)
To generate a diff of this commit:
cvs rdiff -r1.90 -r1.90.4.1 src/sys/netinet/tcp_var.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: pr/12790 CVS commit: [netbsd-1-6] src/sys/netinet
Date: Fri, 5 Sep 2003 13:42:53 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Sep 5 13:42:53 UTC 2003
Modified Files:
src/sys/netinet [netbsd-1-6]: tcp_timer.c
Log Message:
Pull up revision 1.58 (requested by tls in ticket #1445):
path MTU discovery blackhole detection.
PR 12790 (sorry for not committing it for a long time)
To generate a diff of this commit:
cvs rdiff -r1.57 -r1.57.10.1 src/sys/netinet/tcp_timer.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.49 2026/05/14 01:52:41 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home