------- Comment From ru...@us.ibm.com 2017-02-21 10:05 EDT------- Thanks Steve.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1646956 Title: ping -I support broken in yakkety version 3:20150815-2ubuntu3 (multicast test failure) Status in iputils package in Ubuntu: Fix Committed Bug description: == Comment: #0 - HARSHA THYAGARAJA - 2016-11-15 03:42:59 == ---Problem Description--- Multicast failing for Shiner interface on Ubuntu 16.10 (bnx2x) Machine Type = S822l1 ---Steps to Reproduce--- On Host: Enable multicast for the test interface 1. echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 2. ip link set enP5p1s0f1 allmulticast on root@ltciofvtr-s822l1:~# ifconfig enP5p1s0f1 enP5p1s0f1: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST> mtu 1500 inet 170.1.1.20 netmask 255.255.255.0 broadcast 170.1.1.255 inet6 fe80::9abe:94ff:fe5c:f1c1 prefixlen 64 scopeid 0x20<link> ether 98:be:94:5c:f1:c1 txqueuelen 1000 (Ethernet) RX packets 488 bytes 50254 (50.2 KB) RX errors 0 dropped 442 overruns 0 frame 0 TX packets 25 bytes 2226 (2.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 226 memory 0x3d4001000000-3d40017fffff On Peer: --> catch the Test interface from the multicast group ping 224.0.0.1 -I enP4p1s0f2 | grep 170.1.1.20 ---uname output--- Linux ltciofvtr-s822l1 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:01:16 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux == Comment: #9 - Kevin W. Rudd - 2016-11-28 15:40:24 == I'm able to replicate this behavior in a KVM environment with Yakkety, so it does not appear to be related to the specific type of interface. From my testing, it looks like the SO_BINDTODEVICE option is not being honored, so both broadcasts and multicasts are going out the default route device instead of the device specified by -I option to ping. I am unable to replicate this on a xenial host with the same 4.8.0-27 kernel version. so I suspect some other setting is interfering with the ability to bind the output to a specific device. From my own testing: Xenial: # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:15:b7:ba brd ff:ff:ff:ff:ff:ff inet 10.168.122.139/24 brd 10.168.122.255 scope global enp0s6 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe15:b7ba/64 scope link valid_lft forever preferred_lft forever 3: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:e1:35:be brd ff:ff:ff:ff:ff:ff inet 192.168.122.139/24 brd 192.168.122.255 scope global enp0s1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fee1:35be/64 scope link valid_lft forever preferred_lft forever # ping -I enp0s6 -i 30 224.0.0.1 PING 224.0.0.1 (224.0.0.1) from 10.168.122.139 enp0s6: 56(84) bytes of data. 64 bytes from 10.168.122.139: icmp_seq=1 ttl=64 time=0.063 ms 64 bytes from 10.168.122.100: icmp_seq=1 ttl=64 time=0.435 ms (DUP!) ^C ... Yakkety: # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:be:97:ab brd ff:ff:ff:ff:ff:ff inet 10.168.122.100/24 brd 10.168.122.255 scope global enp0s5 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:febe:97ab/64 scope link valid_lft forever preferred_lft forever 3: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:30:d0:14 brd ff:ff:ff:ff:ff:ff inet 192.168.122.100/24 brd 192.168.122.255 scope global enp0s1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe30:d014/64 scope link valid_lft forever preferred_lft forever # ping -I enp0s5 -i 30 224.0.0.1 PING 224.0.0.1 (224.0.0.1) from 10.168.122.100 enp0s5: 56(84) bytes of data. 64 bytes from 192.168.122.100: icmp_seq=1 ttl=64 time=0.115 ms 64 bytes from 192.168.122.139: icmp_seq=1 ttl=64 time=1.65 ms (DUP!) ^C ... Note that the Yakkety system received answers from the hosts on the 192.168.122 network (the network associated with the route for 224.0.0.1). == Comment: #10 - Kevin W. Rudd - 2016-11-30 18:45:59 == This appears to be due to differences in the version of ping on each release. The ping binary from xenial works just fine when copied over to my yakkety test guest. == Comment: #12 - Kevin W. Rudd - 2016-11-30 19:58:54 == It looks like a key change between version 20121221 and 20150815 is ping4_send_probe() and the switch from using sendmsg (which allows passing ancillary data like ipi_ifindex=if_nametoindex("enp0s2")) to using sendto which is not getting any interface information. == Comment: #16 - Kevin W. Rudd - 2016-12-02 14:30:07 == I can confirm that this is not PPC64-specific. I can replicate the same change of "-I" support in an x86_64 yakkety guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1646956/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
