MTU breakage in f20

[Ed Greshko]

On 11/03/14 09:20, Wolfgang S. Rupprecht wrote:
> Ed Greshko <ed.greshko at greshko.com> writes:
>> [egreshko at meimei ~]$ ping -s 1200 wifi   (my gw)
>> PING wifi.greshko.com (192.168.1.1) 1200(1228) bytes of data.
>> 1208 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=1 ttl=64 time=0.487 ms
>> 1208 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=2 ttl=64 time=0.501 ms
>> So, no trouble here.  Fully updated F20 system.
> Hmm. I didn't really believe it could be an across the board problem
> without anyone else noticing, but that leaves me with the question as to
> what is going on here.  I've got a similar claimed mtu of 1500.   
>
>     [wolfgang at arbol ~]$ ip link show p34p1
>     3: p34p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
>         link/ether 08:60:6e:74:6f:e2 brd ff:ff:ff:ff:ff:ff
>
> Using a bit of binary search it turns out my largest working ping is 512
> bytes.  That is a very suspicious number because it is power of two and
> the actual packet still has a handful of bytes slapped onto the front
> making it a non power of two.   
>
>     [wolfgang at arbol ~]$ ping -s 512 gw
>     PING gw.wsrcc.com (192.168.35.1) 512(540) bytes of data.
>     520 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=1 ttl=64 time=0.538 ms
>     520 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=2 ttl=64 time=0.521 ms
>     520 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=3 ttl=64 time=0.453 ms
>     ^C
>     --- gw.wsrcc.com ping statistics ---
>     3 packets transmitted, 3 received, 0% packet loss, time 2001ms
>     rtt min/avg/max/mdev = 0.453/0.504/0.538/0.036 ms
>     [wolfgang at arbol ~]$ ping -s 513 gw
>     PING gw.wsrcc.com (192.168.35.1) 513(541) bytes of data.
>     ^C
>     --- gw.wsrcc.com ping statistics ---
>     9 packets transmitted, 0 received, 100% packet loss, time 7999ms
>
>     [wolfgang at arbol ~]$ 
>
> I've turned off all the hardware accelerators that ethtool knows about.
> No change.
>
>     [wolfgang at arbol ~]$ ethtool -k p34p1
>     Features for p34p1:
>     rx-checksumming: off
>     tx-checksumming: off
>             tx-checksum-ipv4: off
>             tx-checksum-ip-generic: off [fixed]
>             tx-checksum-ipv6: off [fixed]
>             tx-checksum-fcoe-crc: off [fixed]
>             tx-checksum-sctp: off [fixed]
>     scatter-gather: off
>             tx-scatter-gather: off
>             tx-scatter-gather-fraglist: off [fixed]
>     tcp-segmentation-offload: off
>             tx-tcp-segmentation: off
>             tx-tcp-ecn-segmentation: off [fixed]
>             tx-tcp6-segmentation: off [fixed]
>     udp-fragmentation-offload: off [fixed]
>     generic-segmentation-offload: off
>     generic-receive-offload: off
>     large-receive-offload: off [fixed]
>     rx-vlan-offload: off
>     tx-vlan-offload: off
>     ntuple-filters: off [fixed]
>     receive-hashing: off [fixed]
>     highdma: off [fixed]
>     rx-vlan-filter: off [fixed]
>     vlan-challenged: off [fixed]
>     tx-lockless: off [fixed]
>     netns-local: off [fixed]
>     tx-gso-robust: off [fixed]
>     tx-fcoe-segmentation: off [fixed]
>     tx-gre-segmentation: off [fixed]
>     tx-ipip-segmentation: off [fixed]
>     tx-sit-segmentation: off [fixed]
>     tx-udp_tnl-segmentation: off [fixed]
>     tx-mpls-segmentation: off [fixed]
>     fcoe-mtu: off [fixed]
>     tx-nocache-copy: off
>     loopback: off [fixed]
>     rx-fcs: off
>     rx-all: off
>     tx-vlan-stag-hw-insert: off [fixed]
>     rx-vlan-stag-hw-parse: off [fixed]
>     rx-vlan-stag-filter: off [fixed]
>     l2-fwd-offload: off [fixed]
>     busy-poll: off [fixed]
>     [wolfgang at arbol ~]$ 
>
> What is left?  Some weirdness caused by my router announcing a low MTU
> but Fedora not reporting it?  I'm grasping at straws here.

I've not made any adjustments to my tcp/ip stack.  My ethtool output is slightly different than yours but that may be a red herring.

What I would do is use "wireshark" with a capture filter of "icmp" and see what is going out on the wire.  What I would do is "ping -c 1 -s 2000 gw" and then check to see that 2 packets are being sent out with the first one being marked as a fragment.


-- 
If you can't laugh at yourself, others will gladly oblige.