ping -I support broken in yakkety version 3:20150815-2ubuntu3 (multicast test failure)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| iputils (Ubuntu) |
Fix Released
|
Undecided
|
Steve Langasek | ||
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/
2. ip link set enP5p1s0f1 allmulticast on
root@ltciofvtr-
enP5p1s0f1: flags=4675<
inet 170.1.1.20 netmask 255.255.255.0 broadcast 170.1.1.255
inet6 fe80::9abe:
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-
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,
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,
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:
valid_lft forever preferred_lft forever
3: enp0s1: <BROADCAST,
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:
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,
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,
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:
valid_lft forever preferred_lft forever
3: enp0s1: <BROADCAST,
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:
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=
== 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.
| bugproxy (bugproxy) wrote sosreport for multicast failure | #1 |
| tags: | added: architecture-all bugnameltc-148714 severity-medium targetmilestone-inin--- |
| Changed in ubuntu: | |
| assignee: | nobody → Taco Screen team (taco-screen-team) |
| affects: | ubuntu → iputils (Ubuntu) |
| bugproxy (bugproxy) wrote Comment bridged from LTC Bugzilla | #2 |
| bugproxy (bugproxy) wrote | #3 |
| bugproxy (bugproxy) wrote | #4 |
| tags: |
added: targetmilestone-inin1704 removed: targetmilestone-inin--- |
| bugproxy (bugproxy) wrote | #5 |
| Steve Langasek (vorlon) wrote | #6 |
| Changed in iputils (Ubuntu): | |
| assignee: | Taco Screen team (taco-screen-team) → Steve Langasek (vorlon) |
| status: | New → Fix Committed |
| bugproxy (bugproxy) wrote | #7 |
| Launchpad Janitor (janitor) wrote | #8 |
| Changed in iputils (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| bugproxy (bugproxy) wrote | #9 |
Default Comment by Bridge