Red Hat Bugzilla – Bug 1373333
[ppc64]-t take no effect when ping multicast
Last modified: 2017-08-01 16:47:16 EDT
Description of problem: ttl still stay 1 when ping 237.1.1.1 with -t 5 Version-Release number of selected component (if applicable): 3.10.0-500.el7.ppc64 RHEL-7.3-20160901.1 How reproducible: Always Steps to Reproduce: 1. use tcpdump to get packet on nic 2. ping multicast on nic with -t 5 Actual results: ttl in packet is still 1 Expected results: ttl in packet should be 5 Additional info: [root@ibm-p720-02-lp3 ~]# tcpdump -i eth0 host 237.1.1.1 -nn -vvv tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 23:04:37.251952 IP (tos 0x0, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.73.194.106 > 237.1.1.1: ICMP echo request, id 10702, seq 1, length 64 [root@ibm-p720-02-lp3 ~]# ping 237.1.1.1 -I eth0 -c 1 -t 5 ==== on X86_64: [root@ibm-x3650m5-03 ~]# tcpdump -i eno1 host 237.1.1.1 -nn -vvv tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes 21:09:53.735008 IP (tos 0x0, ttl 5, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.73.130.171 > 237.1.1.1: ICMP echo request, id 2722, seq 1, length 64 [root@ibm-x3650m5-03 ~]# ping 237.1.1.1 -I eno1 -t 5 -c 1
The problem also existed on RHEL-7.2GA: [root@ibm-p720-02-lp9 ~]# uname -a Linux ibm-p720-02-lp9.rhts.eng.pek2.redhat.com 3.10.0-327.el7.ppc64 #1 SMP Thu Oct 29 17:33:57 EDT 2015 ppc64 ppc64 ppc64 GNU/Linux [root@ibm-p720-02-lp9 ~]# ping 237.1.1.1 -t 5 -c 1 -I eth0 [root@ibm-p720-02-lp9 ~]# tcpdump -i eth0 host 237.1.1.1 -nn -vvv tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 01:20:48.688596 IP (tos 0x0, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.73.194.112 > 237.1.1.1: ICMP echo request, id 11035, seq 1, length 64
Do you still have a reproducer? I can't reproduce this on my machines and I'm still waiting for a real testing machine. I *think* that I found the problem: https://github.com/iputils/iputils/blob/master/ping.c#L860: if (setsockopt(sock->fd, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, 1) == -1) { perror ("ping: can't set multicast time-to-live"); exit(2); } I think that this takes only the first byte from the ttl value (not sure what that means on the ppc64, probably nothing good). It should probably say something like: if (setsockopt(sock->fd, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl)) == -1) // NOTICE THE sizeof(ttl)
(In reply to Jan Synacek from comment #2) > Do you still have a reproducer? I can't reproduce this on my machines and > I'm still waiting for a real testing machine. > I reserved a ppc64 machine in beaker: ibm-p8-kvm-05-guest-08.rhts.eng.bos.redhat.com and I can reproduce the problem: [root@ibm-p8-kvm-05-guest-08 ~]# tcpdump -i eth0 host 237.1.1.1 -nnle -vvv tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 20:29:43.652007 52:54:00:69:dc:08 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.16.68.148 > 237.1.1.1: ICMP echo request, id 12126, seq 1, length 64 [root@ibm-p8-kvm-05-guest-08 ~]# ping 237.1.1.1 -t 5 -c 1 I have extend the reserve time to 48 hrs, You can use the system if you need.
I don't need the system anymore, thank you! Meanwhile, I managed to get my own machine and created a patch: https://github.com/iputils/iputils/pull/78
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1987