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
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". :-)
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...
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.
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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I.R.S.: We've got what it takes to take what you've got! - ----------------------------------------------------------------------