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 3C2361381F3 for ; Sun, 1 Sep 2013 12:57:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 073B2E0CB8; Sun, 1 Sep 2013 12:57:40 +0000 (UTC) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BF038E0C57 for ; Sun, 1 Sep 2013 12:57:33 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id j13so1152395wgh.29 for ; Sun, 01 Sep 2013 05:57:32 -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=c7Yzq5C5eXKekqylJ6rmrNCR840tp4aPEnxtisug+dg=; b=yHQE5nWBuSWEp1jx7pD3Ik4ziCraytafHVKP7WV7my9TcrMa9yNVbDvjOF5/s9/L7x xgTfoPifx1nu4ftLrsFpkOpUpeP3X9dR5RbR35ikEeq+yjBx0aIBb5VZGjtcjG5mvIVM sdqB05Sh4EUxY5JfkA1Bdu8cZ/CPOr5cRKZtY6bYkeF3xSpCRi2Pg8AaNAn+mdH/oWtV tIVV+YYgwch8M+ihFAZNtSKaLfLYNF/Svm5FT5mF1Bn/T2ToL7BkejC0EpD/OtOYk+3D uUMpCACyd7Qs/ir8ZZBbsbfNgXoKV36ifKSAQsfOcgFJubnaoLd9R2qwPk6E5044Jkv/ su4g== X-Received: by 10.180.84.97 with SMTP id x1mr9727463wiy.4.1378040252362; Sun, 01 Sep 2013 05:57:32 -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 r6sm10415299wiw.0.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 05:57:31 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] PMTUD Date: Sun, 1 Sep 2013 13:57:09 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.7-gentoo; KDE/4.10.5; x86_64; ; ) References: <201309010937.48181.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="nextPart1423677.hZo8b6cy7o"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201309011357.12792.michaelkintzios@gmail.com> X-Archives-Salt: 239bfa6c-6037-423a-a8da-6b261232282e X-Archives-Hash: e382eade194d7dc3d495b122be51d7d7 --nextPart1423677.hZo8b6cy7o Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 01 Sep 2013 12:17:28 Grant wrote: > > Communications between IPv4 end points use PMTUD by setting a Don't > > Fragment (DF) bit in the headers of the outgoing packet. If a > > router/server along the path has a smaller MTU, it will drop that packet > > and respond with an ICMP 'Destination Unreachable -- Fragmentation > > Needed' packet including its smaller MTU value. Upon receiving this > > smaller packet value the initiating host will dynamically reduce the > > size of the outgoing packets, until the packet arrives at its intended > > destination. PMTUD should always be switched on in any well behaving > > network implementation, but here's the rub: some network nodes, > > firewalls, servers are configured to never respond with *any* ICMP > > packets (because they think that this is a way to avoid DDoS problems > > and the like). Therefore, the initiating host keeps sending large > > packets never knowing that they are dropped on the way. This network > > problem is known as a PMTUD blackhole and is explained better here: >=20 > Could ICMP packets not getting through be to blame for my proxy server > problem? My laptop can't seem to ping anyone (blocked at the firewall > in this hotel I suppose) and certainly the proxy server can't ping my > laptop. Not all ICMP packets are relevant to detecting the MTU of a node. A correc= tly=20 implemented node will return an ICMP Fragmentation Needed (Type 3, Code 4)= =20 packet, with its MTU value. This kind of ICMP packets should not be blocke= d=20 at firewalls. Use ping with the do not fragment option to see if packets=20 above a certain size time out, i.e. they are dropped by some offending node= on=20 the way. ping -c 6 -n -M do -s 1472 This will send 6 packets to your server's address having set the do not=20 fragment bit. The packet payload size is set at 1472 to allow for 28 bytes= =20 that are taken up by the IP and ICMP header data. So the total packet size= =20 would be 1472+28=3D1500, the usual ethernet packet size. If the MTU of the server is less than 1500 bytes, you will get a response=20 containing "Frag needed and DF set", otherwise you will get pong responses,= =20 like e.g. 1480 bytes from XXX.XX.XXX.XXX: icmp_seq=3D1 ttl=3D121 time=3D66.5 ms If there is a black hole in the circuit you will be getting timeouts. Star= t=20 reducing the size of the packet if you are getting time outs, say by 10 byt= es=20 at a time. When you arrive at or below the corresponding size of the MTU o= f a=20 blackhole you will start getting responses. Of course, if the hotel's firewall is blocking all outgoing/incoming pings= =20 this sort of diagnostic test will not be useful. =2D-=20 Regards, Mick --nextPart1423677.hZo8b6cy7o 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) iQEcBAABAgAGBQJSIzmoAAoJELAdA+zwE4YejdcH/0SucLXe55rh4mKxcwp7vmXA /BOsAWo0JqCax4YeY1QdQ4vL3CgHeAdOn5Cr8M9/ES+IzwdvwOKdHh80aSJJqqzT dzBuQvLH6hCD93iJjbbWdbUmHptlHARAdL/qKQjzdn6Teokkzd/R/Bhft9Ppd1rN EjZ9JhIPDE1NG3oOULwYn1Yq+udGoAQ0W+bqOYWhemogtiGNarUvgPHayjd76ro4 KrIiWXLua3NpK276tX3DcqeeyjuB4yud6ET1RpZ/vdmWxcVNt6wHTrWkvB0CZG8r /0ca8nopQJmGvVmCLNwOy/ml4UOf05r8OM2ccS4ebt8ODy4UFpJctiFpp7ilRXA= =0nsS -----END PGP SIGNATURE----- --nextPart1423677.hZo8b6cy7o--