ping -R on Fedora 18 d does not work (firewalld problem?)

[Kevin Wilson]

Hello,
I try:
 ping -R www.google.com

I get:
PING www.google.com (173.194.113.112) 56(124) bytes of data.

but the list of nodes does not appear, and I wait for more than 5 minutes.

traceroute www.google.com gives immediately the list of nodes.

This is fedora 18, iptables  stopped (and flushed), firewalld stopped.

Could it be somehow due to not flushing firewalld rules ? (I don't
know much about firewalld)

regards,
Kevin

[Ed Greshko]

On 06/17/13 13:18, Kevin Wilson wrote:
> Hello,
> I try:
>  ping -R www.google.com
>
> I get:
> PING www.google.com (173.194.113.112) 56(124) bytes of data.
>
> but the list of nodes does not appear, and I wait for more than 5 minutes.
>
> traceroute www.google.com gives immediately the list of nodes.
>
> This is fedora 18, iptables  stopped (and flushed), firewalld stopped.
>
> Could it be somehow due to not flushing firewalld rules ? (I don't
> know much about firewalld)

-R     ping  only.   Record  route.  Includes the RECORD_ROUTE option in
              the ECHO_REQUEST packet and displays the route buffer on returned
              packets.   Note  that the IP header is only large enough for nine
              such routes.  Many hosts ignore or discard this option.

I think "Many" should be replaced with "Most".  :-)

[poma]

On 17.06.2013 08:06, Ed Greshko wrote:
> On 06/17/13 13:18, Kevin Wilson wrote:
> > Hello,
> > I try:
> >  ping -R www.google.com
> >
> > I get:
> > PING www.google.com (173.194.113.112) 56(124) bytes of data.
> >
> > but the list of nodes does not appear, and I wait for more than 5 minutes.
> >
> > traceroute www.google.com gives immediately the list of nodes.
> >
> > This is fedora 18, iptables  stopped (and flushed), firewalld stopped.
> >
> > Could it be somehow due to not flushing firewalld rules ? (I don't
> > know much about firewalld)
>   -R     ping  only.   Record  route.  Includes the RECORD_ROUTE option in
>           the ECHO_REQUEST packet and displays the route buffer on returned
>           packets.   Note  that the IP header is only large enough for nine
>           such routes.  Many hosts ignore or discard this option.
>
>
> I think "Many" should be replaced with "Most".  :-)

It's almost impossible to determine.
In one's lifetime. :)
However, I found something interesting regarding 'iptables'.
Guess what. Procedure which includes 'iptables-save/restore' as
described in "Making changes persistent"[1] doesn't work.
Hippity hop hooray!

poma

[1]
https://fedoraproject.org/wiki/How_to_edit_iptables_rules#Making_changes_per...

[Tim]

Allegedly, on or about 17 June 2013, Kevin Wilson sent:
> Hello,
> I try:
>  ping -R www.google.com
>
> I get:
> PING www.google.com (173.194.113.112) 56(124) bytes of data.
>
> but the list of nodes does not appear, and I wait for more than 5 minutes.

Things do not *have* to respond to pings, so a ping can only test how it
responds to pings, rather than be a definitive test of being able to
reach something.

When you're accessible to the world, and every byte costs you money, you
may decide to disable all but the essential traffic.
> traceroute www.google.com gives immediately the list of nodes.

I seem to recall traceroute does, or can, use a different protocol.
Read the manuals.
> Could it be somehow due to not flushing firewalld rules ? (I don't
> know much about firewalld)

Unless you've made special rules, Fedora tends to allow this sort of
traffic.

I get a different IP responding to www.google.com, there are some
responses to pings, and to some of the hops along the route.

[Rick Stevens]

On 06/17/2013 09:40 PM, Tim issued this missive:
> Allegedly, on or about 17 June 2013, Kevin Wilson sent:
> > Hello,
> > I try:
> >   ping -R www.google.com
> >
> > I get:
> > PING www.google.com (173.194.113.112) 56(124) bytes of data.
> >
> > but the list of nodes does not appear, and I wait for more than 5 minutes.
>
> Things do not *have* to respond to pings, so a ping can only test how it
> responds to pings, rather than be a definitive test of being able to
> reach something.

Correct. It is not at all uncommon to configure a system to not respond
to ICMP (ping) queries. Especially if you're a target like Google.
> > traceroute www.google.com gives immediately the list of nodes.
>
> I seem to recall traceroute does, or can, use a different protocol.

traceroute can use several protocols. By default, it uses TCP port
33434, but it can use ICMP if told to ("traceroute -I").

Note that while the traceroute may return data, it's returning data
from each hop on its way to the target. The target itself may not
respond. In fact, it's very, VERY common for hardware load balancers to
block traceroutes. And if the target doesn't respond to a ping, odds
are it won't respond to a traceroute either. You might get to the last
hop before the target, but you won't get the target.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-     I.R.S.: We've got what it takes to take what you've got!       -
----------------------------------------------------------------------