MTU breakage in f20

Wolfgang S. Rupprecht wolfgang.rupprecht at gmail.com
Mon Nov 3 01:20:05 UTC 2014


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.

-wolfgang


More information about the users mailing list