From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id ADE8E1381F3 for ; Sun, 1 Sep 2013 08:38:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF2B2E0D89; Sun, 1 Sep 2013 08:38:10 +0000 (UTC) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 11BE4E0D23 for ; Sun, 1 Sep 2013 08:38:08 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id q55so2813967wes.22 for ; Sun, 01 Sep 2013 01:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=vs436p5gOXXHuivO/z5mTaU2wmdg7VbKRa93lc31hJI=; b=lIA603x2+UdLSde2mzBO9rXBhEBuSLZL57aoM1ZPT7/ZU/p6GHjn4y/4YA4H3cOaBm xrK6B2rkvM4/rjKdQ4zSj1X4guXif6CAPdCPoiFXargNyJ7M+TAm18NemAzVsTaCTE1L Ra9RDl6Wz+6MA22BnuzGnf7Fr7EaNU399XRtU9mhMGIH+7jYIFtwNEThPCK0oLU1VfR5 wfaqFYdDQ37p/q6jpgoDWXK/pbxBmyxwatjErj63C67RQCjIN9U5TI4/QC5XCXoPmid7 3/W75O/6vvM9n/dyvBQO1zkz+RIRqP1nfPTVQFl2cy45vBdfm1HyO9cEgcNRw3WvCSnN sZhg== X-Received: by 10.180.20.33 with SMTP id k1mr8943738wie.21.1378024687722; Sun, 01 Sep 2013 01:38:07 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id fv10sm8548860wic.0.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 01:38:07 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] PMTUD Date: Sun, 1 Sep 2013 09:37:46 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.7-gentoo; KDE/4.10.5; x86_64; ; ) References: <201308271527.09340.michaelkintzios@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2174612.9o1xTh8ks9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201309010937.48181.michaelkintzios@gmail.com> X-Archives-Salt: ef5931d8-1460-4a05-b5e3-2a8974172703 X-Archives-Hash: c5ee2ef1a5929819f4dc94568005c29b --nextPart2174612.9o1xTh8ks9 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 01 Sep 2013 08:40:20 Grant wrote: > >> How is PMTUD enabled/disabled on Gentoo? I've recently been made > >> aware of the existence of MTU and I'm wondering if mine is set > >> properly for a cell phone tethered connection. >=20 > Thanks Mick. Can you generally rely on PMTUD to set the MTU optimally > or should this be experimented with when changing connections? Short answer: default Linux machine settings behave properly as network=20 devices and acknowledge packets larger than their MTU value with the=20 appropriate response. Longer answer: Communications between IPv4 end points use PMTUD by setting a Don't Fragmen= t=20 (DF) bit in the headers of the outgoing packet. If a router/server along t= he=20 path has a smaller MTU, it will drop that packet and respond with an ICMP=20 'Destination Unreachable -- Fragmentation Needed' packet including its smal= ler=20 MTU value. Upon receiving this smaller packet value the initiating host wi= ll=20 dynamically reduce the size of the outgoing packets, until the packet arriv= es=20 at its intended destination. PMTUD should always be switched on in any wel= l=20 behaving network implementation, but here's the rub: some network nodes,=20 firewalls, servers are configured to never respond with *any* ICMP packets= =20 (because they think that this is a way to avoid DDoS problems and the like)= =2E =20 Therefore, the initiating host keeps sending large packets never knowing th= at=20 they are dropped on the way. This network problem is known as a PMTUD blac= k=20 hole and is explained better here: http://tools.ietf.org/html/rfc2923 Some MSWindows servers were notoriously bad at this, but I think that moder= n=20 configurations have corrected their buggy ways. Linux machines have PMTUD= =20 switched on by default and behave properly. If you are still troubled by the proxy connection stalling problem, have yo= u=20 tried transferring large files over the network using scp/sftp to see if yo= u=20 are also getting similar symptoms? This would isolate it to the applicatio= n=20 level (squid) or if the problem remains would point to network configuratio= n=20 issues. =2D-=20 Regards, Mick --nextPart2174612.9o1xTh8ks9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABAgAGBQJSIvzcAAoJELAdA+zwE4Ye4WMIAMN8lQ6e6976SUixEBfYI212 6j5sL/8MYLuNVyyCEr7d4ZPt6kDs8SCkkTxnFS5/jSmUCusiYpXHcdPx86Pat+yA qpEexphZd94tkRnDNBNGOv20pQ7FW8uOtq4pJ4XwaWvNZrnuHPQ3IknI0GKhZseR 7UfwLW0XayvFnHpHpqGXk8dAAhCtyumvyYN4EEomcad9Ct8mCTqlG1zrtadxzsq4 hTCW9W3Bq4Ee5aSiEG9SACmU9p4Hl6sCLTBGGOqDMbU3hyRkqzrsw9wpNadyW8e9 EHl6T/11YOn3Lk6giJKQPEvkOPAwmY7jwPsUDKwr7bleuzSgvqrCeiK8i6qXslc= =CewO -----END PGP SIGNATURE----- --nextPart2174612.9o1xTh8ks9--