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 utility installed.
There are plenty of commands, applications, and utilities exists to find type of 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.
TTL Values
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.
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
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
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 / OS | Version | Protocol | TTL |
AIX | TCP | 60 | |
AIX | UDP | 30 | |
Android | 3.2.1 | TCP and ICMP | 64 |
Android | 5.1.1 | TCP and ICMP | 64 |
AIX | 3.2, 4.1 | ICMP | 255 |
BSDI | BSD/OS 3.1 and 4.0 | ICMP | 255 |
Compa | Tru64 v5.0 | ICMP | 64 |
Cisco | ICMP | 254 | |
DEC Pathworks | V5 | TCP and UDP | 30 |
Foundry | ICMP | 64 | |
FreeBSD | 2.1R | TCP and UDP | 64 |
FreeBSD | 3.4, 4.0 | ICMP | 255 |
FreeBSD | 5 | ICMP | 64 |
HP-UX | 9.0x | TCP and UDP | 30 |
HP-UX | 10.01 | TCP and UDP | 64 |
HP-UX | 10.2 | ICMP | 255 |
HP-UX | 11 | ICMP | 255 |
HP-UX | 11 | TCP | 64 |
Irix | 5.3 | TCP and UDP | 60 |
Irix | 6.x | TCP and UDP | 60 |
Irix | 6.5.3, 6.5.8 | ICMP | 255 |
juniper | ICMP | 64 | |
MPE/IX (HP) | ICMP | 200 | |
Linux | 2.0.x kernel | ICMP | 64 |
Linux | 2.2.14 kernel | ICMP | 255 |
Linux | 2.4 kernel | ICMP | 255 |
Linux | Red Hat 9 | ICMP and TCP | 64 |
MacOS/MacTCP | 2.0.x | TCP and UDP | 60 |
MacOS/MacTCP | X (10.5.6) | ICMP/TCP/UDP | 64 |
NetBSD | ICMP | 255 | |
Netgear FVG318 | ICMP and UDP | 64 | |
OpenBSD | 2.6 & 2.7 | ICMP | 255 |
OpenVMS | 07.01.2002 | ICMP | 255 |
OS/2 | TCP/IP 3.0 | 64 | |
OSF/1 | V3.2A | TCP | 60 |
OSF/1 | V3.2A | UDP | 30 |
Solaris | 2.5.1, 2.6, 2.7, 2.8 | ICMP | 255 |
Solaris | 2.8 | TCP | 64 |
Stratus | TCP_OS | ICMP | 255 |
Stratus | TCP_OS (14.2-) | TCP and UDP | 30 |
Stratus | TCP_OS (14.3+) | TCP and UDP | 64 |
Stratus | STCP | ICMP/TCP/UDP | 60 |
SunOS | 4.1.3/4.1.4 | TCP and UDP | 60 |
SunOS | 5.7 | ICMP and TCP | 255 |
Ultrix | V4.1/V4.2A | TCP | 60 |
Ultrix | V4.1/V4.2A | UDP | 30 |
Ultrix | V4.2 – 4.5 | ICMP | 255 |
VMS/Multinet | TCP and UDP | 64 | |
VMS/TCPware | TCP | 60 | |
VMS/TCPware | UDP | 64 | |
VMS/Wollongong | 1.1.1.1 | TCP | 128 |
VMS/Wollongong | 1.1.1.1 | UDP | 30 |
VMS/UCX | TCP and UDP | 128 | |
Windows | for Workgroups | TCP and UDP | 32 |
Windows | 95 | TCP and UDP | 32 |
Windows | 98 | ICMP | 32 |
Windows | 98, 98 SE | ICMP | 128 |
Windows | 98 | TCP | 128 |
Windows | NT 3.51 | TCP and UDP | 32 |
Windows | NT 4.0 | TCP and UDP | 128 |
Windows | NT 4.0 SP5- | 32 | |
Windows | NT 4.0 SP6+ | 128 | |
Windows | NT 4 WRKS SP 3, SP 6a | ICMP | 128 |
Windows | NT 4 Server SP4 | ICMP | 128 |
Windows | ME | ICMP | 128 |
Windows | 2000 pro | ICMP/TCP/UDP | 128 |
Windows | 2000 family | ICMP | 128 |
Windows | Server 2003 | 128 | |
Windows | XP | ICMP/TCP/UDP | 128 |
Windows | Vista | ICMP/TCP/UDP | 128 |
Windows | 7 | ICMP/TCP/UDP | 128 |
Windows | Server 2008 | ICMP/TCP/UDP | 128 |
Windows | 10 | ICMP/TCP/UDP | 128 |
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 remote system, you can use the Ping command to get the name of OS.
5 comments
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?
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.
Hi,
Thanks a lot
Very nice article
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.
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.