In some of the traces (taken by tcpdump) the packet order (sorted by packet number) is not always same as the timestamp order, any reason this would happen? asked 23 Oct '16, 23:09  yhzs8 |
One Answer:
At least some versions of Linux, when running on a multiprocessor machine - which means any multi-core machine - may process two packets on different CPU cores, and the first packet to arrive may take longer to process, for whatever reason, than the second packet to arrive, and therefore the second packet may be queued up on a socket before the first one is. tcpdump and Wireshark capture traffic using the libpcap library, and libpcap uses PF_PACKET sockets on Linux, so libpcap may, therefore, see the second packet before the first packet; libpcap just presents packets to the application as they arrive, without sorting them by the time stamp, and both tcpdump and Wireshark write out packets as they arrive, without sorting them by the time stamp. answered 26 Oct '16, 14:23  Guy Harris ♦♦ So if the traces is based on the socket-queue-ordering, there must be another entity that "timestamps" the packets which timestamps them differently than the socket-queue-ordering, which entity is it? (27 Oct '16, 01:12) yhzs8 |
Is timestamp part of a protocol header?
No, timestamp is generated by the capturing hardware/software. Do you capture on only one interface or more?
@Luffy: No I didnt mean the "TCP option Timestamp", rather the "time" field shown on the Wireshark for each packet.
@Sindy: No, it was just taken on a single interface.
On what OS is tcpdump running?
It is taken on Linux, SUSE