Re: DF (Don't frag) issues

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