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 QueenslandReceived on Mon May 02 2005 - 13:16:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:33 UTC