From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:01:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0745C16A4CE for ; Mon, 25 Apr 2005 18:01:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B0C43D49 for ; Mon, 25 Apr 2005 18:01:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 11757 invoked from network); 25 Apr 2005 18:02:23 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Apr 2005 18:02:23 -0000 Message-ID: <426D306B.7010000@freebsd.org> Date: Mon, 25 Apr 2005 20:01:15 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andre Oppermann References: <426426AE.2060406@uq.edu.au><42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> In-Reply-To: <426D2307.97D15253@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: David Malone cc: qingli@freebsd.org cc: Matthew Sullivan cc: silby@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2005 18:01:19 -0000 Andre Oppermann wrote: > Matthew Sullivan wrote: > >>2/ The bug itself is also a problem, as it cannot be guarenteed that the >>host returning the ICMP 'need frag' will fill in a suggested mtu, so >>that also needs to be looked at (but I guess you know that already ;-)) > > I'm testing a fix right now. Unfortunatly the whole situation is a lot > more complex than thought at first. While stepping through the code > I found some other incorrect assumptions. Ok, I've put up a patch that should fix all issues: http://www.nrg4u.com/freebsd/icmp_df_pmtu-20050425.diff It does the following things: - Change icmp_error() to pass the MTU as an integer argument instead of the interface pointer. This gives much more flexibility for returning the MTU value for strange constructs and tunnel stuff. Even now it removes a nasty XXX hack in IPSEC support in ip_forward(). - Handling of received ICMP Needfrag messages. The logic was broken for the cases where the ICMP didn't contain a suggested value. This brokeness is in there since 5.2R and comes from my cleanup of the routing table and introduction of TCP hostcache. However there is no way to fix it at all. It was broken even before I broke it more. The idea behind the old code was to step down the MTU when we got a ICMP Needfrag by one step and try again. Unfortunatly it is very likely that the tcp window was open by a few segments already when we hit this. This gets us a number of those ICMP's in rapid succession each stepping us one down. Not good and MTU going down to 296 or even 64 bytes. There is no fix other than falling back to the default MTU if we get ICMP Needfrag without a suggested MTU in them. I have no idea how many devices send them without an MTU suggestion. Probably not many, if any. Qing, Silby, David, please have a look at the patch. -- Andre