Home Linux Tips & Tricks How To Identify Operating System Using TTL Value And Ping Command

How To Identify Operating System Using TTL Value And Ping Command

By sk
2,119 Views

Did you know that we can identify which operating system is running on a remote system by simply pinging it? Yes! In this brief guide, we will see how to determine operating system with TTL value and Ping command. This method should work on any operating system that has Ping command line utlity.

There are plenty of commands, applications, and utilities exists to find out the OS of a remote system. However, finding operating system type with TTL is super easy!

You can quickly detect whether a system is running with Linux, or Windows or any other OS by looking at the TTL value from the output of the ping command. You don't need any extra applications to detect a remote system's OS.

The TTL value varies depends on the version of an operating system and device.

The default initial TTL value for Linux/Unix is 64, and TTL value for Windows is 128.

Here is the default initial TTL values for popular operating systems such as Linux, FreeBSD, Mac OS, Solaris and Windows.

Operating systems TTL Values
Operating systems TTL Values

You can view the complete list of TTL values for different operating systems and devices at the end.

Detect remote host's operating system with TTL value

TTL, stands for Time to live, is a timer value included in packets sent over TCP/IP-based networks that tells the recipients how long to hold or use the packet or any of its included data before expiring and discarding the packet or data.

And the Ping command is used to check the connectivity and reachability of system or device on local area network or wide area network. Ping command comes pre-installed in most operating systems.

To view the TTL value of a Linux/Windows host, simply ping the host from itself or from other systems on the network:

Example:

$ ping -c5 localhost

Sample output from my Fedora desktop:

PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.063 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.057 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.070 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.067 ms
64 bytes from localhost (::1): icmp_seq=5 ttl=64 time=0.056 ms

--- localhost ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4096ms
rtt min/avg/max/mdev = 0.056/0.062/0.070/0.005 ms
Ping Linux host
Ping Linux host

As you can see, I get 64 as TTL value in the above output. Because it is a Linux system.

What about the Windows hosts? Let us see what we get if we ping a Windows system.

I am going to ping the Windows 10 desktop from my Fedora desktop. The IP address of My Windows 10 is 192.168.122.239.

$ ping -c5 192.168.122.239

Sample output:

PING 192.168.122.239 (192.168.122.239) 56(84) bytes of data.
64 bytes from 192.168.122.239: icmp_seq=1 ttl=128 time=6.85 ms
64 bytes from 192.168.122.239: icmp_seq=2 ttl=128 time=0.510 ms
64 bytes from 192.168.122.239: icmp_seq=3 ttl=128 time=0.601 ms
64 bytes from 192.168.122.239: icmp_seq=4 ttl=128 time=0.541 ms
64 bytes from 192.168.122.239: icmp_seq=5 ttl=128 time=0.558 ms

--- 192.168.122.239 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4088ms
rtt min/avg/max/mdev = 0.510/1.812/6.851/2.519 ms
Ping Windows host from Linux host
Ping Windows host from Linux host

Note the the TTL value? It is 128. The default TTL value for Windows OS is 128.

Initial TTL values

The following table shows the default Initial TTL values of various operating systems and devices.

Device / OSVersionProtocolTTL
AIXTCP60
AIXUDP30
Android3.2.1TCP and ICMP64
Android5.1.1TCP and ICMP64
AIX3.2, 4.1ICMP255
BSDIBSD/OS 3.1 and 4.0ICMP255
CompaTru64 v5.0ICMP64
CiscoICMP254
DEC PathworksV5TCP and UDP30
FoundryICMP64
FreeBSD2.1RTCP and UDP64
FreeBSD3.4, 4.0ICMP255
FreeBSD5ICMP64
HP-UX9.0xTCP and UDP30
HP-UX10.01TCP and UDP64
HP-UX10.2ICMP255
HP-UX11ICMP255
HP-UX11TCP64
Irix5.3TCP and UDP60
Irix6.xTCP and UDP60
Irix6.5.3, 6.5.8ICMP255
juniperICMP64
MPE/IX (HP)ICMP200
Linux2.0.x kernelICMP64
Linux2.2.14 kernelICMP255
Linux2.4 kernelICMP255
LinuxRed Hat 9ICMP and TCP64
MacOS/MacTCP2.0.xTCP and UDP60
MacOS/MacTCPX (10.5.6)ICMP/TCP/UDP64
NetBSDICMP255
Netgear FVG318ICMP and UDP64
OpenBSD2.6 & 2.7ICMP255
OpenVMS07.01.2002ICMP255
OS/2TCP/IP 3.064
OSF/1V3.2ATCP60
OSF/1V3.2AUDP30
Solaris2.5.1, 2.6, 2.7, 2.8ICMP255
Solaris2.8TCP64
StratusTCP_OSICMP255
StratusTCP_OS (14.2-)TCP and UDP30
StratusTCP_OS (14.3+)TCP and UDP64
StratusSTCPICMP/TCP/UDP60
SunOS4.1.3/4.1.4TCP and UDP60
SunOS5.7ICMP and TCP255
UltrixV4.1/V4.2ATCP60
UltrixV4.1/V4.2AUDP30
UltrixV4.2 – 4.5ICMP255
VMS/MultinetTCP and UDP64
VMS/TCPwareTCP60
VMS/TCPwareUDP64
VMS/Wollongong1.1.1.1TCP128
VMS/Wollongong1.1.1.1UDP30
VMS/UCXTCP and UDP128
Windowsfor WorkgroupsTCP and UDP32
Windows95TCP and UDP32
Windows98ICMP32
Windows98, 98 SEICMP128
Windows98TCP128
WindowsNT 3.51TCP and UDP32
WindowsNT 4.0TCP and UDP128
WindowsNT 4.0 SP5-32
WindowsNT 4.0 SP6+128
WindowsNT 4 WRKS SP 3, SP 6aICMP128
WindowsNT 4 Server SP4ICMP128
WindowsMEICMP128
Windows2000 proICMP/TCP/UDP128
Windows2000 familyICMP128
WindowsServer 2003128
WindowsXPICMP/TCP/UDP128
WindowsVistaICMP/TCP/UDP128
Windows7ICMP/TCP/UDP128
WindowsServer 2008ICMP/TCP/UDP128
Windows10ICMP/TCP/UDP128
Initial TTL values

This method may not be accurate all the time. However, it will give an idea of the underlying operating system in a remote system. If you know only the IP address of a remte system, you can use the Ping command to get the name of OS.

You May Also Like

5 comments

Roman Caecescu September 21, 2021 - 9:29 am

The well known DNS server 8.8.8.8 is run by Google.

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=46.2 ms

What does the unusual TTL value of 115 indicated?

Reply
sk September 21, 2021 - 10:32 am

This won’t work through the internet, since the TTL ticks down for each device it routes through. This is to prevent routing loops to infinity so if it gets stuck in a loop the packet will die instead of looping forever.

Reply
Jalal Hajigholamali September 21, 2021 - 3:57 pm

Hi,
Thanks a lot
Very nice article

Reply
Roman Caecescu September 22, 2021 - 12:09 pm

Thank you for your response SK. The article should have mentioned the TTL being reduced by 1 for each routing step since when you wrote in the article ” a remote system”, I understood that to mean a remote host out on the Internet , not a host on my LAN.

If I do a traceroute to 8.8.8.8, 8 hops are shewn, the first being my router. Does that give an indication of the original TTL value, maybe 115 + 8 or possibly a little more (ie an original TTL in the ballpark of 128 maybe) if traceroute is not reporting all the intermediate routers for some reason?

Assuming 128 is correct, that would indicate from your table that the OS was Windows which would suprise me greatly as I doubt that Google would run the DNS service on a Windows OS. If that supposition is correct, it would indicate that Google has changed the TTL to be Windows-like.

Reply
sk September 22, 2021 - 3:11 pm

Yeah, you’re right, Roman. TTL decrement for every device it goes through and it’s done to prevent routing loops. The result may not very reliable all the time. For example, Linux kernel 2.4 used 225, so 64 doesn’t always mean Linux. Also, that number can be changed. Thanks for your detailed reply.

Reply

Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More