* Ping Is Broken
@ 2009-10-09 10:16 Rob Townley
[not found] ` <7e84ed60910090316ne9224fat81d9c79c58fc713b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Rob Townley @ 2009-10-09 10:16 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: CentOS mailing list, Omaha Linux User Group
[-- Attachment #1.1: Type: text/plain, Size: 135 bytes --]
i am hoping this attachment gets through. It deals with bug in ping that
made it very difficult to set up a system with two gateways.
[-- Attachment #1.2: Type: text/html, Size: 146 bytes --]
[-- Attachment #2: ping-bug-demo.sh.post.html --]
[-- Type: text/html, Size: 4447 bytes --]
[-- Attachment #3: Type: text/plain, Size: 163 bytes --]
_______________________________________________
CentOS mailing list
CentOS-IFYaIzF+flcdnm+yROfE0A@public.gmane.org
http://lists.centos.org/mailman/listinfo/centos
^ permalink raw reply [flat|nested] 13+ messages in thread[parent not found: <7e84ed60910090316ne9224fat81d9c79c58fc713b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Ping Is Broken [not found] ` <7e84ed60910090316ne9224fat81d9c79c58fc713b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-10-09 16:34 ` Rob Townley [not found] ` <7e84ed60910090934y2a0d422cr158aa8d15e452f97-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Rob Townley @ 2009-10-09 16:34 UTC (permalink / raw) To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: CentOS mailing list, Omaha Linux User Group [-- Attachment #1.1: Type: text/plain, Size: 4027 bytes --] The following deals with bug in ping that made it very difficult to set up a system with two gateways. ping -I is broken Demonstration that *ping -I is broken*. When specifying the source interface using -I with an *ethX* alias and that interface is not the default gateway interface, then ping fails. When specifying the interface as an ip address, ping works. Search for "Destination Host Unreachable" to find the bug. eth*0* = 4.3.2.8 and the default gateway is accessed through a different interface eth*1*. eth*1* = 192.168.168.155 is used as the device to get to the default gateway. *FAILS *: ping *-I eth0* 208.67.222.222 *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 *WORKS*: ping *-I eth1* 208.67.222.222 *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 The following are actual results which can be reproduced from an up-to-date Fedora 11 or CentOS 5.3 box. Caused a very very long episode of frustration when setting up multi gatewayed systems. * ping using eth0 *: ping -c 2 -B -I eth0 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of data. >From 4.3.2.8 icmp_seq=1 Destination Host Unreachable >From 4.3.2.8 icmp_seq=2 Destination Host Unreachable --- 208.67.222.222 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms , pipe 2 * ping using 4.3.2.8 *: ping -c 2 -B -I 4.3.2.8 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 : 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=562 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=642 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 562.546/602.400/642.255/39.862 ms * ping using eth1 *: ping -c 2 -B -I eth1 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 eth1: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=270 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=629 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 270.128/449.766/629.405/179.639 ms * ping using 192.168.168.155 *: ping -c 2 -B -I 192.168.168.155 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 : 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=585 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=554 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 554.098/569.655/585.212/15.557 ms My source route policy rules: /sbin/ip rule show 0: from all lookup 255 32762: from 4.3.2.8 lookup nic0 32763: from 192.168.168.155 lookup nic1 32764: from 192.168.168.155 lookup nic1 32765: from 4.3.2.8 lookup nic0 32766: from all lookup main 32767: from all lookup default Print out routing tables using /sbin/ip route show table TABLENAME: routing table nic0 : /sbin/ip route show table nic0 default via 4.3.2.1 dev eth0 routing table nic1 : /sbin/ip route show table nic1 default via 192.168.168.1 dev eth1 routing table main : /sbin/ip route show table main 4.3.2.1/27 dev eth0 proto kernel scope link src 4.3.2.8 192.168.168.0/24 dev eth1 proto kernel scope link src 192.168.168.155 169.254.0.0/16 dev eth1 scope link default via 192.168.168.1 dev eth1 routing table default : /sbin/ip route show table default NOTES: cat /etc/iproute2/rt_tables to get your own table names. ping Maintainer YOSHIFUJI Hideaki / USAGI/WIDE Project http://www.skbuff.net/iputils/ Mailing List netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org man ping: -I interface address Set source address to specified interface address. Argument may be *numeric IP address or name of device*. When pinging IPv6 link-local address this option is required. ping -V returns the latest available on CentOS and Fedora and the maintainers website: ping utility, iputils-ss020927 [-- Attachment #1.2: Type: text/html, Size: 5458 bytes --] [-- Attachment #2: Type: text/plain, Size: 163 bytes --] _______________________________________________ CentOS mailing list CentOS-IFYaIzF+flcdnm+yROfE0A@public.gmane.org http://lists.centos.org/mailman/listinfo/centos ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <7e84ed60910090934y2a0d422cr158aa8d15e452f97-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Ping Is Broken [not found] ` <7e84ed60910090934y2a0d422cr158aa8d15e452f97-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-10-09 16:44 ` Rob Townley 2009-10-12 9:47 ` Jarek Poplawski ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Rob Townley @ 2009-10-09 16:44 UTC (permalink / raw) To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: CentOS mailing list, Omaha Linux User Group ping -I is broken The following deals with bug in ping that made it very difficult to set up a system with two gateways. Demonstration that *ping -I is broken*. When specifying the source interface using -I with an *ethX* alias and that interface is not the default gateway interface, then ping fails. When specifying the interface as an ip address, ping works. Search for "Destination Host Unreachable" to find the bug. eth*0* = 4.3.2.8 and the default gateway is accessed through a different interface eth*1*. eth*1* = 192.168.168.155 is used as the device to get to the default gateway. *FAILS *: ping *-I eth0* 208.67.222.222 *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 *WORKS*: ping *-I eth1* 208.67.222.222 *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 The following are actual results which can be reproduced from an up-to-date Fedora 11 or CentOS 5.3 box. Caused a very very long episode of frustration when setting up multi gatewayed systems. * ping using eth0 *: ping -c 2 -B -I eth0 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of data. >From 4.3.2.8 icmp_seq=1 Destination Host Unreachable >From 4.3.2.8 icmp_seq=2 Destination Host Unreachable --- 208.67.222.222 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms , pipe 2 -------------------------------------- The Following all WORK: * ping using 4.3.2.8 *: ping -c 2 -B -I 4.3.2.8 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 : 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=562 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=642 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 562.546/602.400/642.255/39.862 ms * ping using eth1 *: ping -c 2 -B -I eth1 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 eth1: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=270 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=629 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 270.128/449.766/629.405/179.639 ms * ping using 192.168.168.155 *: ping -c 2 -B -I 192.168.168.155 208.67.222.222 PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 : 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=585 ms 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=554 ms --- 208.67.222.222 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 554.098/569.655/585.212/15.557 ms My source route policy rules: /sbin/ip rule show 0: from all lookup 255 32762: from 4.3.2.8 lookup nic0 32763: from 192.168.168.155 lookup nic1 32764: from 192.168.168.155 lookup nic1 32765: from 4.3.2.8 lookup nic0 32766: from all lookup main 32767: from all lookup default Print out routing tables using /sbin/ip route show table TABLENAME: routing table nic0 : /sbin/ip route show table nic0 default via 4.3.2.1 dev eth0 routing table nic1 : /sbin/ip route show table nic1 default via 192.168.168.1 dev eth1 routing table main : /sbin/ip route show table main 4.3.2.1/27 dev eth0 proto kernel scope link src 4.3.2.8 192.168.168.0/24 dev eth1 proto kernel scope link src 192.168.168.155 169.254.0.0/16 dev eth1 scope link default via 192.168.168.1 dev eth1 routing table default : /sbin/ip route show table default NOTES: cat /etc/iproute2/rt_tables to get your own table names. ping Maintainer YOSHIFUJI Hideaki / USAGI/WIDE Project http://www.skbuff.net/iputils/ Mailing List netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org man ping: -I interface address Set source address to specified interface address. Argument may be *numeric IP address or name of device*. When pinging IPv6 link-local address this option is required. ping -V returns the latest available on CentOS and Fedora and the maintainers website: ping utility, iputils-ss020927 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-09 16:44 ` Rob Townley @ 2009-10-12 9:47 ` Jarek Poplawski 2009-10-12 19:14 ` Rob Townley 2009-10-12 20:36 ` Brian Haley [not found] ` <006a01ca4a10$a1a4ba60$e4ee2f20$@com> 2 siblings, 1 reply; 13+ messages in thread From: Jarek Poplawski @ 2009-10-12 9:47 UTC (permalink / raw) To: CentOS mailing list Cc: public-netdev-u79uwXL29TY76Z2rM5mHXA, Omaha Linux User Group On 09-10-2009 18:44, Rob Townley wrote: > ping -I is broken > > The following deals with bug in ping that made it very difficult to set up a > system with two gateways. > > Demonstration that *ping -I is broken*. When specifying the source > interface using -I with an *ethX* alias and that interface is not the > default gateway > interface, then ping fails. When specifying the interface as an ip address, > ping works. Search for "Destination Host Unreachable" to find the bug. > > > eth*0* = 4.3.2.8 and the default gateway is accessed through a different > interface eth*1*. > eth*1* = 192.168.168.155 is used as the device to get to the default > gateway. > *FAILS *: ping *-I eth0* 208.67.222.222 > *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 > *WORKS*: ping *-I eth1* 208.67.222.222 > *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 ... > man ping: > -I interface address > Set source address to specified interface address. > Argument may be *numeric IP address or name of device*. > When pinging IPv6 link-local address this option is required. It seems this description might be misleading that IP address and name of device are equivalent here, while they are treated a bit different. The device name is additionally used in a sendmsg message, probably to guarantee the device is really used (not its address only), so it looks like intended. > ping -V returns the latest available on CentOS and Fedora and the > maintainers website: > ping utility, iputils-ss020927 I guess the patch below could do what you expect in this case, but rather "man" should be fixed... Jarek P. --- --- ping.c.orig 2002-09-20 15:08:11.000000000 +0000 +++ ping.c 2009-10-12 08:51:25.000000000 +0000 @@ -323,7 +323,7 @@ main(int argc, char **argv) perror("ping: icmp open socket"); exit(2); } - +#if 0 if (device) { struct ifreq ifr; @@ -336,7 +336,7 @@ main(int argc, char **argv) cmsg.ipi.ipi_ifindex = ifr.ifr_ifindex; cmsg_len = sizeof(cmsg); } - +#endif if (broadcast_pings || IN_MULTICAST(ntohl(whereto.sin_addr.s_addr))) { if (uid) { if (interval < 1000) { ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 9:47 ` Jarek Poplawski @ 2009-10-12 19:14 ` Rob Townley 2009-10-12 20:43 ` Jarek Poplawski 0 siblings, 1 reply; 13+ messages in thread From: Rob Townley @ 2009-10-12 19:14 UTC (permalink / raw) To: Jarek Poplawski Cc: CentOS mailing list, public-netdev-u79uwXL29TY76Z2rM5mHXA, Omaha Linux User Group On Mon, Oct 12, 2009 at 4:47 AM, Jarek Poplawski <jarkao2@gmail.com> wrote: > > > On 09-10-2009 18:44, Rob Townley wrote: >> ping -I is broken >> >> The following deals with bug in ping that made it very difficult to set up a >> system with two gateways. >> >> Demonstration that *ping -I is broken*. When specifying the source >> interface using -I with an *ethX* alias and that interface is not the >> default gateway >> interface, then ping fails. When specifying the interface as an ip address, >> ping works. Search for "Destination Host Unreachable" to find the bug. >> >> >> eth*0* = 4.3.2.8 and the default gateway is accessed through a different >> interface eth*1*. >> eth*1* = 192.168.168.155 is used as the device to get to the default >> gateway. >> *FAILS *: ping *-I eth0* 208.67.222.222 >> *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 >> *WORKS*: ping *-I eth1* 208.67.222.222 >> *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 > ... >> man ping: >> -I interface address >> Set source address to specified interface address. >> Argument may be *numeric IP address or name of device*. >> When pinging IPv6 link-local address this option is required. > > It seems this description might be misleading that IP address and name > of device are equivalent here, while they are treated a bit different. > The device name is additionally used in a sendmsg message, probably to > guarantee the device is really used (not its address only), so it > looks like intended. > >> ping -V returns the latest available on CentOS and Fedora and the >> maintainers website: >> ping utility, iputils-ss020927 > > I guess the patch below could do what you expect in this case, but > rather "man" should be fixed... Thank you for the patch. i will test it. i was trying to find the problem using gdb and figure out a patch myself. ping used to work the way i expected many many years ago on various *nix systems. Besides, traceroute is broken by the same problem except that traceroute is much more explicit with a -i and -s parameters. Who knows what else is broken by all the meddling in interface name aliases without testing. MultiNic / MultiGatewayed machines are hard enough in Linux, lets not give users a reason to use BSD or Windows. > > Jarek P. > --- > > --- ping.c.orig 2002-09-20 15:08:11.000000000 +0000 > +++ ping.c 2009-10-12 08:51:25.000000000 +0000 > @@ -323,7 +323,7 @@ main(int argc, char **argv) > perror("ping: icmp open socket"); > exit(2); > } > - > +#if 0 > if (device) { > struct ifreq ifr; > > @@ -336,7 +336,7 @@ main(int argc, char **argv) > cmsg.ipi.ipi_ifindex = ifr.ifr_ifindex; > cmsg_len = sizeof(cmsg); > } > - > +#endif > if (broadcast_pings || IN_MULTICAST(ntohl(whereto.sin_addr.s_addr))) { > if (uid) { > if (interval < 1000) { > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 19:14 ` Rob Townley @ 2009-10-12 20:43 ` Jarek Poplawski 0 siblings, 0 replies; 13+ messages in thread From: Jarek Poplawski @ 2009-10-12 20:43 UTC (permalink / raw) To: Rob Townley Cc: CentOS mailing list, public-netdev-u79uwXL29TY76Z2rM5mHXA, Omaha Linux User Group On Mon, Oct 12, 2009 at 02:14:13PM -0500, Rob Townley wrote: > On Mon, Oct 12, 2009 at 4:47 AM, Jarek Poplawski <jarkao2@gmail.com> wrote: > > > > > > On 09-10-2009 18:44, Rob Townley wrote: > >> ping -I is broken > >> > >> The following deals with bug in ping that made it very difficult to set up a > >> system with two gateways. > >> > >> Demonstration that *ping -I is broken*. When specifying the source > >> interface using -I with an *ethX* alias and that interface is not the > >> default gateway > >> interface, then ping fails. When specifying the interface as an ip address, > >> ping works. Search for "Destination Host Unreachable" to find the bug. > >> > >> > >> eth*0* = 4.3.2.8 and the default gateway is accessed through a different > >> interface eth*1*. > >> eth*1* = 192.168.168.155 is used as the device to get to the default > >> gateway. > >> *FAILS *: ping *-I eth0* 208.67.222.222 > >> *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 > >> *WORKS*: ping *-I eth1* 208.67.222.222 > >> *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 > > ... > >> man ping: > >> -I interface address > >> Set source address to specified interface address. > >> Argument may be *numeric IP address or name of device*. > >> When pinging IPv6 link-local address this option is required. > > > > It seems this description might be misleading that IP address and name > > of device are equivalent here, while they are treated a bit different. > > The device name is additionally used in a sendmsg message, probably to > > guarantee the device is really used (not its address only), so it > > looks like intended. > > > >> ping -V returns the latest available on CentOS and Fedora and the > >> maintainers website: > >> ping utility, iputils-ss020927 > > > > I guess the patch below could do what you expect in this case, but > > rather "man" should be fixed... > > Thank you for the patch. i will test it. i was trying to find the > problem using gdb and figure out a patch myself. > > ping used to work the way i expected many many years ago on various > *nix systems. This patch is rather to show the main difference a device name could make here. IMHO it should work in your case (I didn't test it), but as a matter of fact I'm not sure it's the way (route) you expected. > Besides, traceroute is broken by the same problem except that > traceroute is much more explicit with a -i and -s parameters. Who > knows what else is broken by all the meddling in interface name > aliases without testing. > > MultiNic / MultiGatewayed machines are hard enough in Linux, lets not > give users a reason to use BSD or Windows. Linux routing, especially multipath, might be simply different than others, but I wouldn't call it broken (except when it's broken ;-). In this case I don't think it's proven enough: if you change the default route to eth0's in your example it should show there is some consistency in it. It seems "-I eth0" should mean something else than "-I ip_address" yet (where it can matter), and ping does it. It's only not documented enough. Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-09 16:44 ` Rob Townley 2009-10-12 9:47 ` Jarek Poplawski @ 2009-10-12 20:36 ` Brian Haley 2009-10-12 21:28 ` Jarek Poplawski 2009-10-12 21:45 ` Jarek Poplawski [not found] ` <006a01ca4a10$a1a4ba60$e4ee2f20$@com> 2 siblings, 2 replies; 13+ messages in thread From: Brian Haley @ 2009-10-12 20:36 UTC (permalink / raw) To: Rob.Townley; +Cc: netdev, Omaha Linux User Group, CentOS mailing list Rob Townley wrote: > ping -I is broken > > The following deals with bug in ping that made it very difficult to set up a > system with two gateways. > > Demonstration that *ping -I is broken*. When specifying the source > interface using -I with an *ethX* alias and that interface is not the > default gateway > interface, then ping fails. When specifying the interface as an ip address, > ping works. Search for "Destination Host Unreachable" to find the bug. I believe ping is working properly here, see below. > eth*0* = 4.3.2.8 and the default gateway is accessed through a different > interface eth*1*. > eth*1* = 192.168.168.155 is used as the device to get to the default > gateway. > *FAILS *: ping *-I eth0* 208.67.222.222 > *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 > *WORKS*: ping *-I eth1* 208.67.222.222 > *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 > > The following are actual results which can be reproduced from an up-to-date > Fedora 11 or CentOS 5.3 box. Caused a very very long episode of frustration > when setting up multi gatewayed systems. > > > * ping using eth0 *: > > ping -c 2 -B -I eth0 208.67.222.222 > PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of data. > From 4.3.2.8 icmp_seq=1 Destination Host Unreachable > From 4.3.2.8 icmp_seq=2 Destination Host Unreachable In this case ping is doing an SO_BINDTODEVICE to eth0, so the kernel is going to force the packets out of it, even if it isn't the "correct" interface. If you ran tcpdump you'd probably see an ARP resolution failure, or an ICMP from a gateway. This confusion could be cleared-up on the man page. What did you expect to happen in this case? > The Following all WORK: > * ping using 4.3.2.8 *: > > ping -c 2 -B -I 4.3.2.8 208.67.222.222 > PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 : 56(84) bytes of data. > 64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=562 ms > 64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=642 ms In this case ping is going to bind() the source address to 4.3.2.8, but not restrict the interface at all. It works because of the weak end-host model of Linux where that address can be used on any interface, not just the one it is configured on. Your other two examples are similar to this one. -Brian ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 20:36 ` Brian Haley @ 2009-10-12 21:28 ` Jarek Poplawski 2009-10-12 21:45 ` Jarek Poplawski 1 sibling, 0 replies; 13+ messages in thread From: Jarek Poplawski @ 2009-10-12 21:28 UTC (permalink / raw) To: Brian Haley Cc: Rob.Townley, netdev, Omaha Linux User Group, CentOS mailing list Brian Haley wrote, On 10/12/2009 10:36 PM: > Rob Townley wrote: ... >> ping -c 2 -B -I eth0 208.67.222.222 >> PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of data. >> From 4.3.2.8 icmp_seq=1 Destination Host Unreachable >> From 4.3.2.8 icmp_seq=2 Destination Host Unreachable > > In this case ping is doing an SO_BINDTODEVICE to eth0, so the kernel is going > to force the packets out of it, even if it isn't the "correct" interface. If > you ran tcpdump you'd probably see an ARP resolution failure, or an ICMP from > a gateway. > > This confusion could be cleared-up on the man page. What did you expect to > happen in this case? Actually, ping could do it other way: trying to connect with eth0's IP address(es). (Then we would need another option for using a dev like now.) Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 20:36 ` Brian Haley 2009-10-12 21:28 ` Jarek Poplawski @ 2009-10-12 21:45 ` Jarek Poplawski 2009-10-12 23:30 ` Brian Haley 1 sibling, 1 reply; 13+ messages in thread From: Jarek Poplawski @ 2009-10-12 21:45 UTC (permalink / raw) To: Brian Haley Cc: Rob.Townley, netdev, Omaha Linux User Group, CentOS mailing list Brian Haley wrote, On 10/12/2009 10:36 PM: > > In this case ping is doing an SO_BINDTODEVICE to eth0, so the kernel is going > to force the packets out of it, even if it isn't the "correct" interface. If > you ran tcpdump you'd probably see an ARP resolution failure, or an ICMP from > a gateway. BTW, SO_BINDTODEVICE is used only to acquire a source address, not the real connection (unless I miss something). Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 21:45 ` Jarek Poplawski @ 2009-10-12 23:30 ` Brian Haley 2009-10-13 5:10 ` Jarek Poplawski 0 siblings, 1 reply; 13+ messages in thread From: Brian Haley @ 2009-10-12 23:30 UTC (permalink / raw) To: Jarek Poplawski Cc: Rob.Townley, netdev, Omaha Linux User Group, CentOS mailing list Jarek Poplawski wrote: > Brian Haley wrote, On 10/12/2009 10:36 PM: > >> In this case ping is doing an SO_BINDTODEVICE to eth0, so the kernel is going >> to force the packets out of it, even if it isn't the "correct" interface. If >> you ran tcpdump you'd probably see an ARP resolution failure, or an ICMP from >> a gateway. > > BTW, SO_BINDTODEVICE is used only to acquire a source address, not the real > connection (unless I miss something). No, SO_BINDTODEVICE affects routing, as well as incoming packets - it's in macros like INET_MATCH(), from what I've seen it restricts a socket to only use the device specified, irregardless of the source address you're using. For example, you can bind to 127.0.0.1 and send packets out eth0 if sk_bound_dev_if is set to it if I remember correctly. -Brian ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-12 23:30 ` Brian Haley @ 2009-10-13 5:10 ` Jarek Poplawski 2009-10-13 13:48 ` Brian Haley 0 siblings, 1 reply; 13+ messages in thread From: Jarek Poplawski @ 2009-10-13 5:10 UTC (permalink / raw) To: Brian Haley Cc: Rob.Townley, netdev, Omaha Linux User Group, CentOS mailing list On Mon, Oct 12, 2009 at 07:30:26PM -0400, Brian Haley wrote: > > > Jarek Poplawski wrote: > > Brian Haley wrote, On 10/12/2009 10:36 PM: > > > >> In this case ping is doing an SO_BINDTODEVICE to eth0, so the kernel is going > >> to force the packets out of it, even if it isn't the "correct" interface. If > >> you ran tcpdump you'd probably see an ARP resolution failure, or an ICMP from > >> a gateway. > > > > BTW, SO_BINDTODEVICE is used only to acquire a source address, not the real > > connection (unless I miss something). > > No, SO_BINDTODEVICE affects routing, as well as incoming packets - it's in macros > like INET_MATCH(), from what I've seen it restricts a socket to only use the device > specified, irregardless of the source address you're using. For example, you can > bind to 127.0.0.1 and send packets out eth0 if sk_bound_dev_if is set to it if I > remember correctly. I've commented your: "In this case ping is doing an SO_BINDTODEVICE to eth0", so meant: SO_BINDTODEVICE is used *by ping* only to acquire a source address. Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ping Is Broken 2009-10-13 5:10 ` Jarek Poplawski @ 2009-10-13 13:48 ` Brian Haley 0 siblings, 0 replies; 13+ messages in thread From: Brian Haley @ 2009-10-13 13:48 UTC (permalink / raw) To: Jarek Poplawski Cc: Rob.Townley, netdev, Omaha Linux User Group, CentOS mailing list Jarek Poplawski wrote: > I've commented your: "In this case ping is doing an SO_BINDTODEVICE to eth0", > so meant: SO_BINDTODEVICE is used *by ping* only to acquire a source address. Yes, sorry, it was too late here to be reading code :( Setting the oif in the cmsg has the same basic effect since it's going to influence the route lookup. -Brian ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <006a01ca4a10$a1a4ba60$e4ee2f20$@com>]
[parent not found: <7e84ed60910111032s2f03b6dew5c756895872e1a0c@mail.gmail.com>]
[parent not found: <000301ca4b13$60a26e00$21e74a00$@com>]
[parent not found: <7e84ed60910121115i30ec3512uce46cf0ff3b3954c@mail.gmail.com>]
[parent not found: <Pine.LNX.4.64.0910121934360.26068@pakmon.pakint.net>]
* Re: [olug] Ping Is Broken [not found] ` <Pine.LNX.4.64.0910121934360.26068@pakmon.pakint.net> @ 2009-11-22 20:10 ` Rob Townley 0 siblings, 0 replies; 13+ messages in thread From: Rob Townley @ 2009-11-22 20:10 UTC (permalink / raw) To: olug4mgm; +Cc: Omaha Linux User Group, Brian Haley, netdev, jarkao2 On Tue, Oct 13, 2009 at 12:50 AM, Matthew G. Marsh <olug4mgm@paktronix.com> wrote: > > </delurk> > > On Mon, 12 Oct 2009, Rob Townley wrote: > >> On Mon, Oct 12, 2009 at 3:09 AM, Aric Aasgaard <aric@omahax.com> wrote: >>> >>> The interface isn't on the network your trying to ping. >> >> Maybe i don't understand what you are saying, but eth0's ip address is >> 4.3.2.8 and when 4.3.2.8 is passed as the interface, it works. When >> eth0 is passed as the interface name, ping fails. So it isn't a >> problem with the network or routing rules or routing tables, it is a >> problem in being able to address a device alias. > > Actually - not completely. The main problem is that when you call ping with > the -I eth0 then you also are invoking your rule 32762 because when the ping > command goes to use the interface it then runs through the rule set and as > 32762 is the lowest rule it is invoked and your ping packet goes out through > eth0 to the default gateway of table nic0: > > /sbin/ip route show table nic0 > default via 4.3.2.1 dev eth0 > > And I suspect that cannot get to the device you want to ping. > > On the other hand when you specify -I 4.x.x.x to the ping command then the > packet goes out from lo0 using that source address and is routed by the > default rule "from all lookup main" which means it gets routed out the eth1 > interface but with the 4.x address. > > Do you see the difference? > > What gives this away is the following: > > 1: The ping utility is from iputils (Alexey's utility set) and thus behaves > according to the policy structure in the kernel which _does_ differentiate > between IP address assignments and mere network interfaces. Remember - the > IP address DOES NOT belong to an interface and does not even need to be > bound to such in order to function in a Linux kernel. > > 2: When you said "All exhibit the issue that ethX can't be used as an > interface name when the default gateway isn't reached thru ethX." > > That told me that you were slightly confusing the way in which -I works in > Alexey's ping utility. It is confusing considering that you must understand > the difference between interface sourcing and ip address sourcing. > > In summary - > > -I <interface> will use the primary IP address of the named interface AND > act as though it had been sourced from that interface which triggers any > relevant rules, routes, etal. > > -I <IP addr> merely sets the Source address of the packet but then sources > the packet from lo0 and this would invoke the default routing > > Sense? > > Let me know. Thanks!! > > P.S. I am considering starting work on a second edition as I now am back > working in the IT field... > > mgm > >>> How are you attempting to get from one NIC to the other? Not via the same >>> switch I hope. >> >> Both of these nics in all examples are in the same machine. Some have >> ip_forward = 1 and some don't. All exhibit the issue that ethX can't >> be used as an interface name when the default gateway isn't reached >> thru ethX. Even machines with two nics behind the same switch and >> therefore have the same default gateway on each interface exhibit a >> problem referencing the interface by ethX -- however by IP address >> works just fine. So some are behind the same switch and some use >> totally different paths to the internet - either way it is broken. >> >>> >>> May I ask what you are trying to do? There might be an easier way. >> >> i have a bunch of machines with 2 or more nics (HP and Dell Server >> Class) that i will use for many types of projects. The easiest way is >> for ping and tracert to be fixed. it is the first tool in network >> assurance and debugging and it is very broken. i suspect this would >> cause problems for users of VPNs, wireless, and other multi nic >> scenarios. >> >>> >>> As far a multi NIC BSD systems, yeah I got a few pfsense boxes, it is >>> BSD. >>> I started using pfsense when I couldn't get multi WAN Linux to work. >> >> i wish i would have known to give up 2-3 years ago - i knew i wasn't >> that stupid as i have only been using ping for 20 years. i also had >> problems with ping on dd-wrt and as this busybox mailing list shows, i >> am not the only one. Note, these busybox guys didn't test this too >> well because their examples never ping an ip on the other side of a >> wire, but it is the exact same problem. >> http://lists.busybox.net/pipermail/busybox/2009-July/069972.html >> >>> >>> >>> >>> -----Original Message----- >>> From: olug-bounces@olug.org [mailto:olug-bounces@olug.org] On Behalf Of >>> Rob >>> Townley >>> Sent: Sunday, October 11, 2009 12:32 PM >>> To: Omaha Linux User Group >>> Subject: Re: [olug] Ping Is Broken >>> >>> On Sat, Oct 10, 2009 at 8:17 PM, Aric Aasgaard <aric@omahax.com> wrote: >>>> >>>> Does >>>> traceroute -i eth0 -I 208.67.222.222 >>>> using ICMP >>> >>> eth0 = 4.3.2.8, the default gateway is thru eth1. >>> tracert -i eth0 -I 208.67.222.222 FAILS >>> tracert -s 4.3.2.8 -I 208.67.222.222 WORKS >>> tracert -i eth0 208.67.222.222 FAILS >>> tracert -s 4.3.2.8 208.67.222.222 WORKS >>> >>> There is a still a great deal of heated argument on the netdev list on >>> how to make network device naming better. Some want to name >>> interfaces in the order of MAC address, others in the name of bus >>> enumeration, some think symbolic links will make things more >>> complicated, others want it. Please test using the following script. >>> Anybody have a multinic BSD system up that would care to test this. >>> OSX? >>> >>> #!/bin/bash >>> #The following is a script to test source routing thru the network >>> interface alias vs ip address. >>> #Put in your own IP addresses here. >>> ip0=4.3.2.8 >>> ip1=192.168.168.155 >>> for interface in eth0 $ip0 eth1 $ip1; do echo testing $interface; ping >>> -I $interface 208.67.222.222; done; >>> >>>> >>>> or using UDP >>>> traceroute -i eth0 208.67.222.222 >>>> >>>> Work? >>>> >>>> -----Original Message----- >>>> From: olug-bounces@olug.org [mailto:olug-bounces@olug.org] On Behalf Of >>> >>> Rob >>>> >>>> Townley >>>> Sent: Friday, October 09, 2009 11:45 AM >>>> To: netdev@vger.kernel.org >>>> Cc: CentOS mailing list; Omaha Linux User Group >>>> Subject: Re: [olug] Ping Is Broken >>>> >>>> ping -I is broken >>>> >>>> The following deals with bug in ping that made it very difficult to set >>>> up >>> >>> a >>>> >>>> system with two gateways. >>>> >>>> Demonstration that *ping -I is broken*. When specifying the source >>>> interface using -I with an *ethX* alias and that interface is not the >>>> default gateway >>>> interface, then ping fails. When specifying the interface as an ip >>> >>> address, >>>> >>>> ping works. Search for "Destination Host Unreachable" to find the bug. >>>> >>>> >>>> eth*0* = 4.3.2.8 and the default gateway is accessed through a different >>>> interface eth*1*. >>>> eth*1* = 192.168.168.155 is used as the device to get to the default >>>> gateway. >>>> *FAILS *: ping *-I eth0* 208.67.222.222 >>>> *WORKS*: ping *-I 4.3.2.8* 208.67.222.222 >>>> *WORKS*: ping *-I eth1* 208.67.222.222 >>>> *WORKS*: ping *-I 192.168.168.155* 208.67.222.222 >>>> >>>> The following are actual results which can be reproduced from an >>> >>> up-to-date >>>> >>>> Fedora 11 or CentOS 5.3 box. Caused a very very long episode of >>> >>> frustration >>>> >>>> when setting up multi gatewayed systems. >>>> >>>> >>>> * ping using eth0 *: >>>> >>>> ping -c 2 -B -I eth0 208.67.222.222 >>>> PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of >>>> data. >>>> From 4.3.2.8 icmp_seq=1 Destination Host Unreachable >>>> From 4.3.2.8 icmp_seq=2 Destination Host Unreachable >>>> >>>> --- 208.67.222.222 ping statistics --- >>>> 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time >>>> 999ms >>>> , pipe 2 >>>> >>>> -------------------------------------- >>>> The Following all WORK: >>>> * ping using 4.3.2.8 *: >>>> >>>> ping -c 2 -B -I 4.3.2.8 208.67.222.222 >>>> PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 : 56(84) bytes of >>>> data. >>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=562 ms >>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=642 ms >>>> >>>> --- 208.67.222.222 ping statistics --- >>>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms >>>> rtt min/avg/max/mdev = 562.546/602.400/642.255/39.862 ms >>>> >>>> >>>> * ping using eth1 *: >>>> >>>> ping -c 2 -B -I eth1 208.67.222.222 >>>> PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 eth1: 56(84) >>>> bytes of data. >>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=270 ms >>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=629 ms >>>> >>>> --- 208.67.222.222 ping statistics --- >>>> 2 packets transmitted, 2 received, 0% packet loss, time 1000ms >>>> rtt min/avg/max/mdev = 270.128/449.766/629.405/179.639 ms >>>> >>>> >>>> * ping using 192.168.168.155 *: >>>> >>>> ping -c 2 -B -I 192.168.168.155 208.67.222.222 >>>> PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 : 56(84) >>>> bytes of data. >>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=585 ms >>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=554 ms >>>> >>>> --- 208.67.222.222 ping statistics --- >>>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms >>>> rtt min/avg/max/mdev = 554.098/569.655/585.212/15.557 ms >>>> >>>> My source route policy rules: >>>> >>>> /sbin/ip rule show >>>> 0: from all lookup 255 >>>> 32762: from 4.3.2.8 lookup nic0 >>>> 32763: from 192.168.168.155 lookup nic1 >>>> 32764: from 192.168.168.155 lookup nic1 >>>> 32765: from 4.3.2.8 lookup nic0 >>>> 32766: from all lookup main >>>> 32767: from all lookup default >>>> >>>> >>>> >>>> Print out routing tables using /sbin/ip route show table TABLENAME: >>>> routing table nic0 : >>>> /sbin/ip route show table nic0 >>>> default via 4.3.2.1 dev eth0 >>>> >>>> routing table nic1 : >>>> /sbin/ip route show table nic1 >>>> default via 192.168.168.1 dev eth1 >>>> >>>> routing table main : >>>> /sbin/ip route show table main >>>> 4.3.2.1/27 dev eth0 proto kernel scope link src 4.3.2.8 >>>> 192.168.168.0/24 dev eth1 proto kernel scope link src 192.168.168.155 >>>> 169.254.0.0/16 dev eth1 scope link >>>> default via 192.168.168.1 dev eth1 >>>> >>>> routing table default : >>>> /sbin/ip route show table default >>>> >>>> >>>> >>>> >>>> NOTES: cat /etc/iproute2/rt_tables to get your own table names. >>>> >>>> ping Maintainer YOSHIFUJI Hideaki / USAGI/WIDE Project >>>> http://www.skbuff.net/iputils/ >>>> Mailing List netdev@vger.kernel.org >>>> >>>> man ping: >>>> -I interface address >>>> Set source address to specified interface address. >>>> Argument may be *numeric IP address or name of device*. >>>> When pinging IPv6 link-local address this option is >>>> required. >>>> >>>> ping -V returns the latest available on CentOS and Fedora and the >>>> maintainers website: >>>> ping utility, iputils-ss020927 > > -------------------------------------------------- > Matthew G. Marsh > Special Email Addr for OLUG ;-} > Phone: (402) 932-7250 > Email: olug4mgm@paktronix.com > WWW: http://www.paksecured.org > -------------------------------------------------- Matt, without iproute2, ping -I ethX works. leave it to a lawyer to explain away ping failing! (just kidding) it probably does take legalese, but write that new book soon. i never forgot your email. i attempted to add additional routes based on your explanation. It was so long ago that i do not remember the exact details of the attempts, but there was no success. i was not sure if you were thinking it would never work as is or that simply additional routes needed to be added? Regardless, here are some interesting results that i found using the slax live cd without iproute installed which demonstrate ping -I ethX works not resulting in an error. It is not a true test because all interfaces in this vm are using the same gateway. Have you written your new book yet? Downloaded the slax livecd iso from slax.org which appears to not have iproute installed at all, but specifying different ethX interfaces works fine. There is a iproute module that can be downloaded and installed, but it isn't. The same VirtualBox config running Fedora 12 Live, ping fails when specifying anything but the default gateway ethX. Installed on a VirtualBox vm with 4 virtual bridged network cards. Linux slax 2.6.27.27 #1 SMP Wed Jul 22 07:27:34 AKDT 2009 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux Linux version 2.6.27.27 (root@darkstar) (gcc version 4.2.4) #1 SMP Wed Jul 22 07:27:34 AKDT 2009 for ((i=0; i < 4; i++)); do ping -c 1 -I eth${i} 208.67.222.222; done; PING 208.67.222.222 (208.67.222.222) from 192.168.168.219 eth0: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=49 time=1098 ms --- 208.67.222.222 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1098.078/1098.078/1098.078/0.000 ms PING 208.67.222.222 (208.67.222.222) from 192.168.168.231 eth1: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=49 time=156 ms --- 208.67.222.222 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 156.386/156.386/156.386/0.000 ms PING 208.67.222.222 (208.67.222.222) from 192.168.168.157 eth2: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=49 time=143 ms --- 208.67.222.222 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 143.279/143.279/143.279/0.000 ms PING 208.67.222.222 (208.67.222.222) from 192.168.168.229 eth3: 56(84) bytes of data. 64 bytes from 208.67.222.222: icmp_seq=1 ttl=49 time=128 ms --- 208.67.222.222 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 128.547/128.547/128.547/0.000 ms ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-11-22 20:10 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-09 10:16 Ping Is Broken Rob Townley
[not found] ` <7e84ed60910090316ne9224fat81d9c79c58fc713b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-10-09 16:34 ` Rob Townley
[not found] ` <7e84ed60910090934y2a0d422cr158aa8d15e452f97-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-10-09 16:44 ` Rob Townley
2009-10-12 9:47 ` Jarek Poplawski
2009-10-12 19:14 ` Rob Townley
2009-10-12 20:43 ` Jarek Poplawski
2009-10-12 20:36 ` Brian Haley
2009-10-12 21:28 ` Jarek Poplawski
2009-10-12 21:45 ` Jarek Poplawski
2009-10-12 23:30 ` Brian Haley
2009-10-13 5:10 ` Jarek Poplawski
2009-10-13 13:48 ` Brian Haley
[not found] ` <006a01ca4a10$a1a4ba60$e4ee2f20$@com>
[not found] ` <7e84ed60910111032s2f03b6dew5c756895872e1a0c@mail.gmail.com>
[not found] ` <000301ca4b13$60a26e00$21e74a00$@com>
[not found] ` <7e84ed60910121115i30ec3512uce46cf0ff3b3954c@mail.gmail.com>
[not found] ` <Pine.LNX.4.64.0910121934360.26068@pakmon.pakint.net>
2009-11-22 20:10 ` [olug] " Rob Townley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).