Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Sep 2002 03:00:19 -0700 (PDT)
From:      Martin Kaeske <Martin.Kaeske@Stud.TU-Ilmenau.DE>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/42137: Path MTU broken - initial too-large packet continuously resent
Message-ID:  <200209021000.g82A0JwQ095843@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/42137; it has been noted by GNATS.

From: Martin Kaeske <Martin.Kaeske@Stud.TU-Ilmenau.DE>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209021000.g82A0JwQ095843>