DF (Don't frag) issues
Andre Oppermann
andre at freebsd.org
Mon Apr 25 11:01:19 PDT 2005
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
More information about the freebsd-current
mailing list