From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C0359138330 for ; Tue, 20 Sep 2016 15:57:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51C58E0BB9; Tue, 20 Sep 2016 15:57:28 +0000 (UTC) Received: from km35626.keymachine.de (km35626.keymachine.de [87.118.86.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 01014E0B91 for ; Tue, 20 Sep 2016 15:57:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by km35626.keymachine.de (Postfix) with ESMTP id 353BB112471F for ; Tue, 20 Sep 2016 18:09:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at km35626.keymachine.de. Received: from km35626.keymachine.de ([127.0.0.1]) by localhost (km35626.keymachine.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk77Gnk2MOqL for ; Tue, 20 Sep 2016 18:08:59 +0200 (CEST) Received: from grusum.endjinn.de (p4FC96D26.dip0.t-ipconnect.de [79.201.109.38]) by km35626.keymachine.de (Postfix) with ESMTPSA id B9E421124630 for ; Tue, 20 Sep 2016 18:08:59 +0200 (CEST) Received: by grusum.endjinn.de (Postfix, from userid 500) id B3B681702EF; Tue, 20 Sep 2016 17:56:24 +0200 (CEST) Date: Tue, 20 Sep 2016 17:56:50 +0200 From: David Haller To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] {OT} ISP requires MTU below 1500? Message-ID: <20160920155650.2rlyahbqy4tduhtp@grusum.endjinn.de> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20160920024829.0d9b56ea@hal9000.localdomain> <20160920115258.GV7108@ns1.bonedaddy.net> <20160920144615.juwnp76jtqe6ec7y@grusum.endjinn.de> 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: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Organization: What? X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.6.2 (2016-07-01) X-Archives-Salt: 851ce159-66b5-4380-b80e-94df89cf1649 X-Archives-Hash: 3cc48e7c07793ac9481296c60ca4d83e Hello, On Tue, 20 Sep 2016, Grant wrote: [..] >> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com >> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data. >> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms >> >> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms >> >> ==== corresponding tcpdump -n -i eth0 icmp ==== >> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472 >> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp >> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472 >> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp >> ==== >> >> >> Two packets sent and received for 1493 bytes packet size / 1465 bytes >> ping-payload. >> >> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for >> yourself to see, that you'll send/recv 2 packets for each ping-packet >> (and 1472 bytes is the ping-payload that just fits into the standard >> 1500 bytes MTU). > > >Strangely, I'm able to ping with that command even with a very high -s value: > >$ ping -c 4 -M dont -s 9999 www.dslreports.com >PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data. >10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54 >time=331 ms >10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54 >time=329 ms >10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54 >time=329 ms >10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54 >time=329 ms > >4 packets transmitted, 4 received, 0% packet loss, time 3003ms >rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms Look again! You're just looking at the _PING_ packets, not the ICMP/IP packets actually going over the interface! You'll need to run 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but there's two IP packets actually going over the interface, due to the ping-packet being too large and being fragmented. Start the tcpdump in another (x)term before running the "ping" ... If you use '-M do', you should get the "Frag needed and DF set (mtu = NNNN)" error from ping. "-M dont" explicitly allows fragmentation, which you can then see with tcpdump. E.g. a with my MTU of 1492, a ==== ping -n -c 1 -M dont -s 9999 192.168.178.1 ==== PING 192.168.178.1 (192.168.178.1) 9999(10027) bytes of data. 10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms --- 192.168.178.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms ==== results in ==== tcpdump -n -i eth0 icmp ==== 17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, seq 1, length 1472 17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp 17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, seq 1, length 1480 17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp 17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp 17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp 17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp 17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp 17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp ==== Yes, that is just the _one_ ping packet. Read up on the links I gave you about fragmentation and IP(v4) in general a bit ;) It's much better described there than I could ATM. Which does not mean not to ask for stuff that's unclear. HTH, -dnh, who seems to have a knack for translating "techese" to normal language ... Actually, I guess fragmentation can be explained quite nicely by comparing to real-life packets ;) You'd get an basically unlimited supply of courier boys, but you can get just so many incoming and outgoing through the doors ;) *grepping out the appropriate sig for that* -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.