1
1
I am pinging an Android-2.3 pandaboard (Linaro Build) with a Linux Mint 12 laptop using this command :
$ ping -c 5 -t 10 192.168.50.200
PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data.
64 bytes from 192.168.50.200: icmp_req=1 ttl=64 time=360 ms
64 bytes from 192.168.50.200: icmp_req=2 ttl=64 time=401 ms
64 bytes from 192.168.50.200: icmp_req=3 ttl=64 time=404 ms
64 bytes from 192.168.50.200: icmp_req=4 ttl=64 time=402 ms
64 bytes from 192.168.50.200: icmp_req=5 ttl=64 time=603 ms
--- 192.168.50.200 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 360.455/434.506/603.300/85.995 ms
Although I specified a Time To Live of 10, the ping command seems to keep the default 64 value.
- What did I miss here?
- How can I check that my network configuration is not preventing the use of non-64 TTL?
When doing the other way around, ie pinging my laptop from the android device, ttl option (-t) is not taken either. Thanks a lot for your help. Emeric
[EDIT]
# ping -c 10 -t 52 74.125.224.72
PING 74.125.224.72 (74.125.224.72) 56(84) bytes of data.
64 bytes from 74.125.224.72: icmp_seq=1 ttl=52 time=1143 ms
64 bytes from 74.125.224.72: icmp_seq=2 ttl=52 time=81.3 ms
64 bytes from 74.125.224.72: icmp_seq=3 ttl=52 time=80.2 ms
^C
--- 74.125.224.72 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2215ms
rtt min/avg/max/mdev = 80.200/435.170/1143.921/501.162 ms, pipe 2
# ping -c 10 -t 51 74.125.224.72
PING 74.125.224.72 (74.125.224.72) 56(84) bytes of data.
64 bytes from 74.125.224.72: icmp_seq=1 ttl=52 time=78.5 ms
64 bytes from 74.125.224.72: icmp_seq=2 ttl=52 time=78.5 ms
64 bytes from 74.125.224.72: icmp_seq=3 ttl=52 time=81.1 ms
64 bytes from 74.125.224.72: icmp_seq=4 ttl=52 time=78.6 ms
64 bytes from 74.125.224.72: icmp_seq=5 ttl=52 time=84.3 ms
^C
--- 74.125.224.72 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5556ms
rtt min/avg/max/mdev = 78.507/80.237/84.372/2.290 ms
ok, thanks. Making a traceroute leads me to 13 hops. And indeed trying to ping with ttl of 12 failed, whereas ttl of 13 succeeded. Anyway it is just misleading to have a ttl option in ping, and to see a different ttl value in the output. To sum up, you mean that "ping -t" option is useless except for router, right? – m-ric – 2012-05-02T15:50:41.967
There may be some unusual situations that decrement TTL where a router is not involved but I can't think of any off the top of my head. – LawrenceC – 2012-05-02T16:59:42.647
1@m-ric While the busybox detail in my answer is correct, ultrasawblade has the right answer. The response packets are created by the other end, using their own TTL. There is no way to see what TTL remained on the packets they received from you. I guess the real question is "what are you trying to acheive?". Why do you want to influence outgoing TTL in the first place? – Paul – 2012-05-03T03:46:00.117
Ok thanks to both of you for your explanation. To answer "what are you trying to achieve?", it was originally to create some traffic on the wifi to stimulate a BT/WLAN bug when both are tranferring. I came to the -ttl option to know the number of hops between my pc and the wlan terminal (pandabord), then found out that traceroute was the tool I need. But still I wanted to know about this weird ttl option in ping command. Thanks for your time. – m-ric – 2012-05-03T13:05:11.953