DF (Don't frag) issues
Matthew Sullivan
matthew at uq.edu.au
Mon May 2 08:16:00 PDT 2005
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
More information about the freebsd-current
mailing list