Ask Your Question

Infer machine boot time/up-time from network packets?

asked 2019-05-14 14:11:44 +0000

alohawireshark gravatar image

Is it possible to infer machine boot time/up-time from network packets? If so, which packets would I use and how would I do this?

Would the answer to the above questions change if I had access to the data of an authoritative DNS server?

edit retag flag offensive close merge delete


Why specifically an authoritative DNS server?

Jaap gravatar imageJaap ( 2019-05-14 14:20:35 +0000 )edit

I am doing a research project in partnership with a company. The company has authoritative DNS servers.

alohawireshark gravatar imagealohawireshark ( 2019-05-14 14:25:04 +0000 )edit

By "boot time" do you mean "how long the machine took to boot" or do you mean "the wall-clock time when the machine booted"?

By "up-time" do you mean "how long the machine has been running since it was last booted"?

Guy Harris gravatar imageGuy Harris ( 2019-05-14 16:41:43 +0000 )edit

by boot time, I mean the wall-clock time when the machine booted. and yes, by up-time, i mean how long the machine has been running since it was last booted

alohawireshark gravatar imagealohawireshark ( 2019-05-14 18:06:36 +0000 )edit

2 Answers

Sort by » oldest newest most voted

answered 2019-05-15 09:04:24 +0000

Bob Jones gravatar image

You might be referring to the use of TCP timestamps as a way to possibly estimate uptime; as referenced by NMAP, see for that discussion and the caveats to using this information in this manner. They call it uptime guess.

Also SNMP is known to provide uptime, see RFC1213-MIB for the sysUpTime OID. So to add to some of the other techniques described, if the target happens to be queried by a network manager via a non-encrypted SNMP polling routine, then this field might be observed in the packet trace and you could access it. Or, if you are able to make SNMP requests to the host you could generate the query yourself, if you had the community strings and/or password if using SNMPv3. I have found this field to be less than reliable across the whole platform of devices I run across - it might be fine on Windows, Cisco IOS, etc., but as soon as you move away into less mainstream devices and platforms, beware.

edit flag offensive delete link more


it looks like NMAP captures exactly the information I am looking for. Is there a way to get/make an uptime guess from Wireshark packets? Perhaps I can use SYN/ACK/TCP packets, check the headers for a timestamp option, (reasonably?) assume a constant rate of increase in ACK number, and use simple linear extraction to calculate uptime?

As for reliability, we only care about sorting computers, mobile devices and perhaps smart tvs into cohorts based on their uptime, so uptime inaccuracy for obscure devices wouldn't concern us.

alohawireshark gravatar imagealohawireshark ( 2019-05-15 09:26:36 +0000 )edit

NMAP is just reading the packets too, so you should be able to do so as well. But look at all the caveats; timestamp is an option, so if your device does not support it, there will be no assessment. Sounds as if you need a method to do this by hand - so I guess the two obvious approaches are to baseline your known systems to how they react to this; find which ones support the timestamp option by sending TCP SYNs, find if it resets to zero on boot, and then find what the counting rate is. This would be the best approach, because it covers the population of your devices. If your devices are unknown, then maybe review NMAPs algorithm and see if you can emulate it with some reverse engineering and source code review.

Bob Jones gravatar imageBob Jones ( 2019-05-15 09:48:37 +0000 )edit

Thanks Bob. I could test NMAP's uptime calculation using known devices and see how well it performs. However, the population of interest would be millions of unknown devices from around the world. I will look into NMAP's algorithm and look into the source code.

alohawireshark gravatar imagealohawireshark ( 2019-05-16 16:48:58 +0000 )edit

Bear in mind that, as the NMAP documentation says, "The uptime guess is labeled a “guess” because various factors can make it completely inaccurate.", and follows that with some reasons why it may be inaccurate.

Guy Harris gravatar imageGuy Harris ( 2020-04-12 21:32:55 +0000 )edit

answered 2019-05-14 22:46:37 +0000

Guy Harris gravatar image

updated 2019-05-14 22:53:52 +0000

The answer to your question is "only if there's a network protocol whose packets include those times and the machine sends them, or if there's a packet that you know the machine will send early in the boot process".

If, for example, the machine uses DHCP to get configuration information when it boots, and you happen to have a record of when that machine sent out its boot-time DHCP packet - either from a traffic capture or from a log on the DHCP server - you could infer an approximate boot time (not necessarily the time the CPU was reset, and not necessarily the time the machine was up and fully ready for operation, but probably close enough).

And if it happens to, for example, do a DNS query for a particular name at boot time (and either never ever queries for it again or queries differently, you might be able to get that information from the DNS server, if it keeps a log of those requests.

(Or maybe it sends out packets for the Berkeley rwho protocol, or a protocol such as that, which probably would contain the uptime and/or the boot time. That's probably not likely, these days.)

edit flag offensive delete link more


Sounds like a lot of conditions must be met for boot time information to be captured. I have heard that such information is transmitted in the TCP packet, if at all. Is that correct or is boot-time available just in the DHCP packet and/or DNS queries?

alohawireshark gravatar imagealohawireshark ( 2019-05-14 23:08:43 +0000 )edit

A TCP packet is just a means of transport of arbitrary network data, nothing inherently related to boot up time. So what you heard was probably incomplete. Also the boot up time isn't available in a DHCP packet or DNS queries. You may be able to infer from the presence of specific packets of these protocols that the system has booted, but there's no guarantee.

Something must have set you on the path of DNS, and I wonder what that is. Just a hunch, or a solid idea? Was there talk about Dynamic DNS maybe?

Jaap gravatar imageJaap ( 2019-05-15 06:50:53 +0000 )edit

If the exercise is just to determin boot time and uptime and the host is Linux based I would design a process polling the servers at regular intervals and doing:

12:34:39 up 77 days, 56 min,  2 users,  load average: 2.61, 2.27, 2.15

If uptime is less than previous uptime there has been a reboot and the time can be calculated I would imagine there's some entry in the syslog too.. Looking at network packets seems to be the wrong thing to do.

Anders gravatar imageAnders ( 2019-05-15 10:37:55 +0000 )edit

If the exercise is just to determine boot time and uptime and the host is UN*X-based, running the uptime command on that host will probably work; uptime isn't a Linux command, it was originally a BSD command, adopted by many OSes including Linux.

Guy Harris gravatar imageGuy Harris ( 2019-05-15 17:32:37 +0000 )edit

I have heard that such information is transmitted in the TCP packet

A TCP packet has a TCP header and TCP payload, where the payload is data for a protocol running on top of TCP. The TCP header has nothing in it that represents a date and time of day; the TCP Timestamps Option is an option, so it's not even guaranteed to be present in a TCP header, and the clock from which it comes is "simply a monotonically non-decreasing serial number, without any connection to time". It's definitely not anything that can be turned into a boot time, as it's monotonically non-decreasing, and it can't be turned into an uptime, as it's not guaranteed to increment by 1 every N seconds for some fixed value of N (which could be a fraction of a second).

Guy Harris gravatar imageGuy Harris ( 2020-04-12 21:04:52 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-05-14 14:11:44 +0000

Seen: 595 times

Last updated: May 15 '19