Date: Mon, 25 Apr 2005 20:01:15 +0200 From: Andre Oppermann <andre@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues Message-ID: <426D306B.7010000@freebsd.org> In-Reply-To: <426D2307.97D15253@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?426D306B.7010000>