Date: Tue, 03 May 2005 01:14:42 +1000 From: Matthew Sullivan <matthew@uq.edu.au> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues Message-ID: <427643E2.4070008@uq.edu.au> In-Reply-To: <42763D42.BB3B5416@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?427643E2.4070008>