Re: MTU breakage in f20 (solved)
Ed Greshko ed.gres...@greshko.com writes: As I mentioned in a previous message, I would have suggested rebooting the GWwhich may also solve it as it may not be an actual port problem just that it got into a condition. :-) It would be nice if it were that simple. That switch was only a year and change old. Just enough to take it out of the 1 year warranty. Rebooting all around is the first thing I did. -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20 (solved)
On Mon, 2014-11-03 at 03:30 -0800, Wolfgang S. Rupprecht wrote: That switch was only a year and change old. Just enough to take it out of the 1 year warranty. Check your local trading standards. Here, one year warranties are not exactly 365 days, they have to be extended by a reasonable amount relative to how long a product really ought to last for. -- tim@localhost ~]$ uname -rsvp Linux 3.16.6-203.fc20.i686 #1 SMP Sat Oct 25 13:08:51 UTC 2014 i686 All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists. George Orwell's '1984' was supposed to be a warning against tyranny, not a set of instructions for supposedly democratic governments. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20
On 11/03/14 08:16, Wolfgang S. Rupprecht wrote: It looks like something broke recently that severely limits the MTU in Fedora 20 when running under NM. Are other people seeing this too? Here I'm pinging my upstream lan-to-wan gateway. A 1200 byte ping fails while a 500 byte one succeeds. I see the same thing when pinging between two identical, fully up-to-date f20 systems. wolfgang@arbol ~]$ ping -s 1200 gw PING gw.wsrcc.com (192.168.35.1) 1200(1228) bytes of data. ^C --- gw.wsrcc.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2000ms [wolfgang@arbol ~]$ ping -s 500 gw PING gw.wsrcc.com (192.168.35.1) 500(528) bytes of data. 508 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=1 ttl=64 time=0.503 ms 508 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=2 ttl=64 time=0.460 ms 508 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=3 ttl=64 time=0.456 ms 508 bytes from gw.wsrcc.com (192.168.35.1): icmp_seq=4 ttl=64 time=0.454 ms ^C --- gw.wsrcc.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 0.454/0.468/0.503/0.025 ms [wolfgang@arbol ~]$ [egreshko@meimei ~]$ ip link show p128p1 2: p128p1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 [egreshko@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 [egreshko@meimei ~]$ ping -s 7000 wifi PING wifi.greshko.com (192.168.1.1) 7000(7028) bytes of data. 7008 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=1 ttl=64 time=0.563 ms 7008 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=2 ttl=64 time=0.511 ms [egreshko@meimei ~]$ ping -s 500 wifi PING wifi.greshko.com (192.168.1.1) 500(528) bytes of data. 508 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=1 ttl=64 time=0.423 ms 508 bytes from wifi.greshko.com (192.168.1.1): icmp_seq=2 ttl=64 time=0.458 ms So, no trouble here. Fully updated F20 system. -- If you can't laugh at yourself, others will gladly oblige. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20
On Mon, 03 Nov 2014 08:25:32 +0800 Ed Greshko wrote: So, no trouble here. I've had some trouble, but only in very odd circumstances: I have a f20 machine hosting a slew of virtual machines on a bridge network with the virtual machines on their own separate subnet on one bridge and the f20 machine serving as a router. Some of the virtual machines (I detected no pattern, I've got lots of different vintage linux distros in the VMs) could not successfully talk NFS to old servers that use UDP. This seemed to have something to do with MTU and routing UDP packets. Wireshark would show errors about UDP packets that needed to be split, then show different errors about being unable to split them. I forget exactly how I fixed it - I think it was by installing a newer kernel than the one that came with f20 at the time I first installed the host. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20
Ed Greshko ed.gres...@greshko.com writes: [egreshko@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@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@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@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@arbol ~]$ I've turned off all the hardware accelerators that ethtool knows about. No change. [wolfgang@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@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 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20
On 11/03/14 09:20, Wolfgang S. Rupprecht wrote: Ed Greshko ed.gres...@greshko.com writes: [egreshko@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@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@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@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@arbol ~]$ I've turned off all the hardware accelerators that ethtool knows about. No change. [wolfgang@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@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. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20
On 11/03/14 09:50, Ed Greshko wrote: 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. And, since you said you had the problem in a F20---F20 situation I'd use wireshark on the receiving side as well to check what is being received. And, in the event that the F20 systems are connected via 10BaseT to ports on your gwI'd reboot the gw. :-) -- If you can't laugh at yourself, others will gladly oblige. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20 (solved)
The problem turned out to be my switch dying in a funny way. When I moved the computer's ethernet from the switch (Netgear GS108E-100NAS) to a spare port on the gateway, large pings started working. Thanks for everyone helping to reason through this. The observation that it wasn't a general fedora problem helped a lot. -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: MTU breakage in f20 (solved)
On 11/03/14 10:18, Wolfgang S. Rupprecht wrote: The problem turned out to be my switch dying in a funny way. When I moved the computer's ethernet from the switch (Netgear GS108E-100NAS) to a spare port on the gateway, large pings started working. Thanks for everyone helping to reason through this. The observation that it wasn't a general fedora problem helped a lot. As I mentioned in a previous message, I would have suggested rebooting the GWwhich may also solve it as it may not be an actual port problem just that it got into a condition. :-) -- If you can't laugh at yourself, others will gladly oblige. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
