ttl option in ping is not recognized

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

m-ric

Posted 2012-05-02T13:22:58.617

Reputation: 317

Answers

The TTL set on outgoing traffic is a system wide parameter on most operating systems, and set the same for all outgoing traffic. It doesn't have anything to do with ICMP responses.

The only situation in where a system would need to decrement the received TTL is when forwarding an exact copy of a packet with rewritten source and destination addresses out of another interface, i.e. when acting as a router. ICMP Echo requests don't fall in that category.

Nonetheless, you can check for sure by running a packet sniffer on the host and look at a capture record of incoming traffic, or looking at firewall logs if your operating system has firewall software installed that supports logging.

LawrenceC

Posted 2012-05-02T13:22:58.617

Reputation: 63 487

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

The pandaboard runs busybox to handle most common shell commands. They are built into the busybox binary rather than run as separate executables like on a traditional linux machine.

The busybox ping command only has a subset of the "proper" options available in the standard ping executable.

Perhaps there is a full ping binary you can install if you need ttl.

Paul

Posted 2012-05-02T13:22:58.617

Reputation: 52 173

Thanks Paul. ttl option is described in busybox ping though, thus I believe it is recognized. But it seems that the ttl displayed in the output of the ping command is the callee's ttl, not the caller's ttl. Do you know? – m-ric – 2012-05-02T14:12:36.260

Hmmm, at least android built-in ping has the [-t ttl] option. I don't use the busybox ping command. – m-ric – 2012-05-02T14:15:27.457

Hi @Emeric - the link in my answer goes to the busybox documentation that shows it doesn't support -t. Where are you seeing that it does? Note that the usage text with these commands are often directly lifted from the executable and so don't always reflect functionality. Also, what built-in android ping are you referring to? – Paul – 2012-05-02T23:34:33.037

Hi Paul, I actually used android built-in ping command, not busybox ping command. Android's ping says it has -t option, ping --help at least says so. But maybe it is not implemented? I just checked external/ping/ping.c and saw that usage() references it. So does common_options function with case 't'. Then Android built-in ping accepts -t I believe :). My question is misleading I confess.

– m-ric – 2012-05-03T03:13:59.197