Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am pinging an Android-2.3 pandaboard (Linaro Build) with a Linux Mint 12 laptop using this command :

$ ping -c 5 -t 10
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=64 time=360 ms
64 bytes from icmp_req=2 ttl=64 time=401 ms
64 bytes from icmp_req=3 ttl=64 time=404 ms
64 bytes from icmp_req=4 ttl=64 time=402 ms
64 bytes from icmp_req=5 ttl=64 time=603 ms

--- 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.

  1. What did I miss here?
  2. 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


# ping -c 10 -t 52
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=52 time=1143 ms
64 bytes from icmp_seq=2 ttl=52 time=81.3 ms
64 bytes from icmp_seq=3 ttl=52 time=80.2 ms
--- 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
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=52 time=78.5 ms
64 bytes from icmp_seq=2 ttl=52 time=78.5 ms
64 bytes from icmp_seq=3 ttl=52 time=81.1 ms
64 bytes from icmp_seq=4 ttl=52 time=78.6 ms
64 bytes from icmp_seq=5 ttl=52 time=84.3 ms
--- 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
share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer
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 May 2 '12 at 15:50
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 May 2 '12 at 16:59
@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 May 3 '12 at 3:46
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 May 3 '12 at 13:05

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.

share|improve this answer
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 May 2 '12 at 14:12
Hmmm, at least android built-in ping has the [-t ttl] option. I don't use the busybox ping command. – m-ric May 2 '12 at 14:15
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 May 2 '12 at 23:34
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 May 3 '12 at 3:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.