I need to record the departure times of packets that are being sent, but I can't seem to find an option for that. My set up can be simplified as follows: data transfer between 2 machines via wifi. I need to record departure times from machine 1 and arrival times at machine 2. I am aware that I should be able to calculate the departure time from time of arrival and time spent traveling, but this will not work for my purposes. Anyone know how this can be done on wireshark or another way, as simply as possible? asked 08 Nov '15, 10:12  hithere |
One Answer:
Not sure I understand what you mean. Capturing at both machine 1 and machine 2 should give you the most precise value. If you want to capture only on machine 2, there is no way to determine the departure time except the one you've described, unless the packets contain an absolute timestamp. In any case (absolute timestamp or capturing on both machines), the time on both machine 1 and machine 2 would have to be synchronised. answered 08 Nov '15, 10:32  sindy showing 5 of 6 show 1 more comments |
Synchronizing the machines won't keep the machines synchronized "enough" (as I need them to be) because the "frequency of the synchronization" via packets is not as high as I need. Hence, my needing to record departure times for packets as they are being sent. The goal is to synchronize the data after the data transfer is finished.
I apologize if I am not using the proper vernacular, I am not a computer scientist/programmer by training.
Appreciate your time!
The terminology is OK, but the goal was not clear (and I am still in doubt). If I get you right, you need to eliminate irregularities in packet transfer delay (which can be quite big over WiFi) when reconstructing the data from the received packets at machine 2. In such case, a timestamp on application level is your only option, because neither TCP nor UDP headers contain any timestamp value. For reconstruction of time distance between two subsequently sent packets, a relative timestamp is enough (i.e. the sending machine need not be synchronised to any external reference).
RTP is a typical example of protocol which uses such kind of timestamp.
Wireshark, as a monitoring tool, can show you what happened, but it doesn't affect packet transfer timing or contents.
Suppose that I am only transferring data in one direction (c drive, for example): from machine 1 to machine 2. Is there a way to record the time at which packets are departing from machine 1? I was hoping that running Wireshark on machine 1 would let me create a file of some kind to store times (according to machine 1's clock) at which individual packets are sent out. This way, it's OK that TCP or UDP headers do not contain timestamp values.
Unfortunately, the relative timestamp doesn't quite do the job (not as accurate as I need). Let me know if there is anything in particular I should clarify further.
Still didn't get what exactly is your problem, so I'll give you an overview of several aspects.
Wireshark running on machine 1 does store copies of the packets as they are sent, and attaches a timestamp to each packet as it stores it. The timestamp contains the time instant when the packet has been given to the network card driver and its accuracy and resolution depend on these properties of the clock of the operating system's kernel.
Wireshark does not store packets to a named file until you ask it to do so manually. So if you need that the file is written on the fly, use tshark instead, which can be asked to write to a .pcap or .pcapng formatted file. As the pcap(ng) file is written using buffers, it is not updated on the disk with each departure/arrival of a packet; on the contrary, the textual output of tshark is updated in real time.
So it may be more useful for you to catch Tshark's textual output on the fly by some script than to parse the pcap(ng) file later.
Regarding the timestamp resolution, as always you have to distinguish between the source resolution and the display resolution.
As an example, on my Windows 7(64 bit), microseconds resolution is available for display, but that does not necessarily mean that the capture resolution is equally good - it may be e.g. non-decimal fractions of a second.
0.000000 0.000000 0.000000 170 0 10.22.30.16 -> 255.255.255.255 UDP Source port: 59351 Destination port: 10019
0.000144 0.000144 0.000144 170 0 10.22.30.16 -> 255.255.255.255 UDP Source port: 59353 Destination port: mvs-capacity
0.304872 0.304728 0.304728 359 0 10.22.30.237 -> 10.22.30.55 UDP Source port: 64512 Destination port: 64198
0.313736 0.008864 0.008864 315 0 10.22.30.21 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1
Which part was the answer to your question, if any?
"Wireshark running on machine 1 does store copies of the packets as they are sent, and attaches a timestamp to each packet as it stores it. The timestamp contains the time instant when the packet has been given to the network card driver and its accuracy and resolution depend on these properties of the clock of the operating system's kernel."
The timestamp you describe here is exactly what I need. How is this done through wireshark? I spoke with a colleague who suggested tcpdump off the top of his head. It seems both are at the mercy of the OS kernel with respect to accuracy and resolution, but I guess that will have to do.
I will be transferring 50-200,000 packets per second for quite a while. And need to generate a data file that will give me timestamps in one column with rest of the packet information in the others.
Thanks again for the help!
Both tcpdump and wireshark use the same libpcap library to capture packets, in another words the packets are captured exactly the same way.
As for "at the mercy of the OS kernel" - in fact the OS kernel is your interface to the most precise hardware clock available in the system, whatever it is. On small embedded systems you may have a clock step of units of milliseconds, on contemporary servers you may have nanoseconds resolution.
But given your concern about timestamp accuracy, and as you've mentioned that computers are not your primary specialization, I'd like to warn you that the process scheduling may be a bigger source of timestamp error than the clock resolution. In the computer, several processes are involved in transferring pieces of data from their original source (disk or some hardware input) to the packet. These processes hand over the data to each other using memory buffers, but they get their CPU time from the scheduler in pieces and not always in the optimal order. As also other processes run in the system, already the travel time of the data from their original source down the sent packet may differ from packet to packet. For the same reason, it may happen that several packets are handed over to the network card driver almost at the same time, so by the timestamps, it looks as if the packet N+1 started being sent before packet N has been sent out completely.