From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:05:05 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 E68C516A4CE; Fri, 29 Apr 2005 22:05:05 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 140E243D3F; Fri, 29 Apr 2005 22:05:05 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFQ00G0HAP718@nemesis.sorbs.net>; Sat, 30 Apr 2005 08:05:32 +1000 (EST) Date: Sat, 30 Apr 2005 08:03:53 +1000 From: Matthew Sullivan In-reply-to: <426E0F5C.3F157398@freebsd.org> To: Andre Oppermann Message-id: <4272AF49.1090400@uq.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <20050426094337.GA44893@walton.maths.tcd.ie> <426E0F5C.3F157398@freebsd.org> cc: David Malone cc: qingli@freebsd.org 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: Fri, 29 Apr 2005 22:05:06 -0000 Andre Oppermann wrote: >David Malone wrote: > > >>On Mon, Apr 25, 2005 at 08:01:15PM +0200, Andre Oppermann wrote: >> >> >>> - 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. >>> >>> >>I wonder if we could look into the quoted IP header and extract the >>length of the IP packet that caused the needs-frag ICMP. That would >>stop us getting in knots when there are a few packets in flight and >>would give us a good idea about where we need to step down from. >> >> > >This is a really clever idea indeed. But it only works if part of >the original packet is attached. Broken implementations are likely >to omit that. But I'll implement your suggestion as well and post >a new patch later this evening. > > > Did you ever do this second patch....? Yesturday I got the first patch installed and compiled (well I got the patch in long before that, but it took until yesturday to get a kernel compiled thanks to the ipf (and others) issues). Results are at: http://scorpion.sorbs.net/ICMP/ It seems to have worked to the point it actually works and the problems go away. However, looking at the dump it appears to have set the MTU to 552, which as the tunnel is 1280 (unencrypted) seems a little inefficient... Comments...? Regards, Mat -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland