Re: aptitude/apt-get hangs during update (plus) on IPv6


On Jun 5, 2011, at 9:46 AM, Pascal Hambourg wrote:

Rick Thomas a écrit :
On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote:

The RFCs say that any conforming implementation MUST handle an MTU of
1280, and may not necessarily handle anything larger.

What is your point in mentionning this requirement? Do you mean that the
server should not send packets bigger than 1280 bytes if it fails to
handle properly path MTU discovery ? If so, I fully agree.

My point is that by setting your MTU to 1280, you have done *your* part. At least you can be assured that all your packets will get thru without fragmentation, even if the host at the other end -- or some intervening router -- is improperly configured.

If the host on the other end sets its MTU to something larger and an intervening router doesn't do fragmentation, they (or the admins of the router) need to fix that. An easy recommendation that you can make in this case (if the server admin on the other end is clueless but willing to help) is for them to set their MTU to 1280 as well. That will fix the problem regardless of intervening routers.

Finding a (possible series of) mis-configured intermediate router(s) and convincing the respective router-admin(s) to fix their configuration is often difficult. It's easier if you have only one person to talk to, the server admin on the other end.


So it makes
sense (if you're going to go to the trouble of setting the MTU in the
first place) to use that number.

Lowering the MTU at the client side does not fix the problem that exists
at the server side. It is just a workaround that works for TCP because
it happens that TCP uses the *outgoing* MTU to calculate the advertised
*incoming* MSS (how weird when you consider that internet routing is
likely to be asymmetric).

In the particular case in hand -- aptitude/apt-get talking to schein.debian.org, that is: the ipv6 avitar of security.debian.org -- I have observed that setting your own MTU to 1280 is all that's necessary.

Enjoy!

Rick


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/EB0DB985-C349-4108-A689-120C3C997801@xxxxxxxxx

Relevant Pages

  • Re: OE6 problem in sending
    ... I haven't seen adjusting MTU value to be a fix for quite a while now! ... >> Hi Pa Bear, ... This is for PC1 cable connect to Router - already ... I tried your 2a Tips but could not find the right combination of MTU ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • [GIT]: Networking
    ... More packet scheduler qdisc locking fixes from Jarek Poplawski. ... Fix by making sure we do xfrm_state_putcalls without the lock ... If you set the MTU of an interface below 68, ... iwlwifi erroneously uses GFP_DMA which will depleat the GFP_DMA ...
    (Linux-Kernel)
  • Re: Can see some sites, not others from Client PC.
    ... to 'fix' it by at first following Microsoft's instructions, ... the instructions were either unclear or in the ... but had gleaned that the problem may be caused by too high a MTU ... I imagine its like packets of data) at the Client? ...
    (microsoft.public.windowsxp.network_web)
  • Re: DF (Dont frag) issues
    ... I've put up a patch that should fix all issues: ... returning the MTU value for strange constructs and tunnel stuff. ... - Handling of received ICMP Needfrag messages. ... if we get ICMP Needfrag without a suggested MTU in them. ...
    (freebsd-current)
  • Re: Site to site tunnel file sharing problem
    ... I thought you might fix this issue by modifying the MTU on the router instead of going to each workstation. ...
    (microsoft.public.windows.server.networking)