From owner-freebsd-bugs Mon Sep 2 3: 0:24 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA22037B400 for ; Mon, 2 Sep 2002 03:00:19 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E13843E65 for ; Mon, 2 Sep 2002 03:00:19 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g82A0JJU095844 for ; Mon, 2 Sep 2002 03:00:19 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g82A0JwQ095843; Mon, 2 Sep 2002 03:00:19 -0700 (PDT) Date: Mon, 2 Sep 2002 03:00:19 -0700 (PDT) Message-Id: <200209021000.g82A0JwQ095843@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Martin Kaeske Subject: Re: kern/42137: Path MTU broken - initial too-large packet continuously resent Reply-To: Martin Kaeske Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/42137; it has been noted by GNATS. From: Martin Kaeske To: logix@foobar.franken.de, freebsd-gnats-submit@FreeBSD.org Cc: jeff@expertcity.com Subject: Re: kern/42137: Path MTU broken - initial too-large packet continuously resent Date: Mon, 2 Sep 2002 11:57:31 +0200 On Mon, Sep 02, 2002 at 10:27:56AM +0200, Harold Gutch wrote: > 1) as the original poster stated, FreeBSD actually is aware that > it got a ICMP NEEDFRAG message, as it does lower the MTU for > that route - it just does not use the new, lowered, MTU. As far as i understand the code in sys/netinet/ip_icmp.c an incoming ICMP message is handled by icmp_input(). This function updates the MTU of a specific route based on src/dst IP-address and the new MTU (suggested by ICMP). After that icmp_input() calls tcp_ctlinput() to inform the TCP layer of the changes. tcp_ctlinput() recognizes that PMTUD has to be performed (that means call tcp_mtudisc) but before that tcp_ctlinput calls in_pcblookup_hash. Due to the wrong src/dst-port values (from the ICMP-response) the lookup fails and tcp_mtudisc is never called. Once my router generates correct responses tcp_mtudisc is called and everything went fine. I didn't look further inside the TCP code but i think there must be some sort of cache that the tcp functions use to generate the packets. That could also be the explanation for the time-outs the OP wrote about, any new TCP connection uses the new values. > 2) I'm seeing the same without ipfilter, even with both, the > router and the client-machine being FreeBSD 4-STABLE. Neither > of the two have IPFILTER in the kernel, both have IPFIREWALL > (ipfw) in it. Hmm, that is strange. Do you get correct ICMP responses (correct src-port and dst-port)? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message