From owner-freebsd-current@FreeBSD.ORG Mon May 2 15:16:00 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 760D116A4CE; Mon, 2 May 2005 15:16:00 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B64A643D66; Mon, 2 May 2005 15:15:59 +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 <0IFV00B1UBQLMZ@nemesis.sorbs.net>; Tue, 03 May 2005 01:15:57 +1000 (EST) Date: Tue, 03 May 2005 01:14:42 +1000 From: Matthew Sullivan In-reply-to: <42763D42.BB3B5416@freebsd.org> To: Andre Oppermann Message-id: <427643E2.4070008@uq.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; 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> <426E0F5C.3F157398@freebsd.org> <4272AF49.1090400@uq.edu.au> <42763D42.BB3B5416@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: Mon, 02 May 2005 15:16:00 -0000 Andre Oppermann wrote: >Matthew Sullivan wrote: > > >>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....? >> >> > >Not yet. I'm hacking on it right now. > > > >>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...? >> >> > >Well, it works. ;-) > >In my local testing things works correctly. For some reason the new code >doesn't get 1280 as new MTU and reverts to the default MTU. Unfortunatly >your tcpdump output doesn't show everything that is returned in the ICMP >packet (it doesn't print the suggested MTU value). Without that I have >trouble figuring out where the problem lies. If you can provide me with >a pure packet dump of the same/replayed sequence you have there I'm able >to trace this down. > > > Give me the switches you want on tcpdump and I'll be happy to provide the packets ;-) Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland