From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-173349-garchives=archives.gentoo.org@lists.gentoo.org>
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 C0CD4138330
for <garchives@archives.gentoo.org>; Tue, 20 Sep 2016 16:36:59 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 706F2E0BE8;
Tue, 20 Sep 2016 16:36:53 +0000 (UTC)
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174])
(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 84C4FE0BCF
for <gentoo-user@lists.gentoo.org>; Tue, 20 Sep 2016 16:36:52 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id n185so20679669qke.1
for <gentoo-user@lists.gentoo.org>; Tue, 20 Sep 2016 09:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=fWRexvVXvjyhAYBSBwwO6/+M+VIcwJZInHw2+d/Ccgo=;
b=RATMy5+FsT1J+LvLwaLnLaYe6LI0JruQ7lAt1s+aqlyCS1MIKQ15lB7gkQ1Xl/lAFg
/f5MEVKypAwgigOLpscsPkbDTtGQAxqL/XTy8q1iK8LjAAkhljKlKsiEop4rPupE32zv
saI4klhPVN3Am6f8Rx0cCnUgPGlBRI+5NOOQyYOerspg93cry50/Y0ILqvAWpaQGSEw4
EgLXsYfgqzhlV+OJ+xyhM8pEvHHmH8VVYaEMchU8ESnpckRYc6UhAFo9fDZ2YTBDsy7i
5fqe8Tuc394DhTXPCQu08NEe+i2TRpCExLFUfttVXqIhJvcSLNa09yKH0LBsav0G0Scc
cHMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=fWRexvVXvjyhAYBSBwwO6/+M+VIcwJZInHw2+d/Ccgo=;
b=PVahW3TMCZUdXkMZOOe/yFs3qd5u2KPoKSQoFSq/ull14rTJqpzSo7SxHhph9VIfcp
4UwG+zoAiN8OcSgof1q8AE7fwMqpvoa1zPNT0NSb9gtXcdoZxRd9XoksL/QYiptkU5gI
KRPktkTBnxJtZtbjkmQNvSs+vcMBams5owaTlAAQ+rXIh59Wlum8GZN7fk6OVnEqs5Sl
EnpUB4Jo+Ox+QQkKA1rAveGlYdCNyS9VsY52urknGu3v1FrVpDf0sh+cdZdnlLRNjudM
kIrmy4ex4a9OVHDkIdu6YMxH82csuckKANIVcmNQPtonwmNYA6/C0lXLudKT4yaiddB0
/hmw==
X-Gm-Message-State: AE9vXwPUXT0M30GSC6BVov5OeWgOshlPlrJji9NCfrBNdof3pagIOqkZhgBJMrPfMhuIu2q8Y0jglRTrmMyciw==
X-Received: by 10.55.201.209 with SMTP id m78mr27262378qkl.308.1474389411200;
Tue, 20 Sep 2016 09:36:51 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.140.38.179 with HTTP; Tue, 20 Sep 2016 09:36:50 -0700 (PDT)
In-Reply-To: <20160920155650.2rlyahbqy4tduhtp@grusum.endjinn.de>
References: <CAN0CFw3qNkNfFH2CM_Pv4mO9QhajrkJ29NRjnuPyrQ6idGc+OA@mail.gmail.com>
<20160920024829.0d9b56ea@hal9000.localdomain> <20160920115258.GV7108@ns1.bonedaddy.net>
<CAN0CFw0AZ+1MO+UObea1XUDBThfGnBOK0T_JrxYRPPotEOdC7A@mail.gmail.com>
<20160920144615.juwnp76jtqe6ec7y@grusum.endjinn.de> <CAN0CFw1K2B5GBOeEGuwQ=8r_kqDG-+cW9eW36mmzcjEemnzm0Q@mail.gmail.com>
<20160920155650.2rlyahbqy4tduhtp@grusum.endjinn.de>
From: Grant <emailgrant@gmail.com>
Date: Tue, 20 Sep 2016 09:36:50 -0700
Message-ID: <CAN0CFw2EkRqoNuLssgWFGabxYWUWTDxLqX=NPjKvxbasQUyg_A@mail.gmail.com>
Subject: Re: [gentoo-user] {OT} ISP requires MTU below 1500?
To: Gentoo mailing list <gentoo-user@lists.gentoo.org>
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: aef4342d-7cb4-4b35-94a9-76486def29ac
X-Archives-Hash: badcc8e814b1a9fce18e73c373c8ad2b
>>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)"
I switched to '-M do' and found that 1464 is the highest size I can
ping without the "Frag needed" error. This means I should add 28 to
that and set my MTU to 1492 across the network?
- Grant
> 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*