Wireshark · Wireshark-users: Re: [Wireshark-users] Timestamp Skew

[Tamás Varga <Tamas.Varga@xxxxxxxxxxxx>]

Hi Lee,

You have to be aware, when you set TimestampMode to 2 for NTP synchronization, 
- it needs some time for NTP initialization (we do wait for 1 hour before capture start) 
- and your capture clock will run at 1/64 sec (15.625 msec) resolution on Intel/AMD computers!

We had initially the default TimestampMode 0 and after reconfiguration our analysis application indicated a lot of protocol errors. We have figured out that the order of some packets have been changed: the SYN-ACK is preceeding the SYN packet! The root-cause is that we have separate tapping for uplink and downlink packets and our analysis tool reads packets from the head of both queues in increasing timestamp order. However, when the timestamps are the same, the behaviour is unpredictable. By switching to sync mode, the timestamp accuracy got poorer, thus in some cases the SYN and SYN-ACK packets received the same timestamp.  This leads in some cases to process SYN-ACK before SYN.

Below, you can see this behavior in an example trace. In case A) the packets are merged in correct order. Case B) shows how TimestampMode 2 infuences the timestamps: both SYN and SYN-ACK packets receive the same timestamp in this capture. Whenever the connection starts at timestamp-tick boundary, we have luck, then it will have different timestamps.

cheers,
 Tamas


A) No synchronization (1us accuracy) 

Uplink:
No	Time			Source		Destination		Info
1	1102510696.180661	172.31.189.13	10.2.168.19	55284 > http [SYN] Seq=919517160 Win=48960 Len=0 MSS=1360 TSV=1281056967 TSER=0 WS=0
2	1102510696.185065	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919517161 Ack=817108211 Win=48960 Len=0 TSV=1281619467 TSER=477122350
3	1102510697.280290	172.31.189.13	10.2.168.19	GET index.html HTTP/1.1
4	1102510697.960600	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919517629 Ack=817108454 Win=48717 Len=0 TSV=1282978842 TSER=477122460
5	1102510698.680567	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919517629 Ack=817109801 Win=47370 Len=0 TSV=1283228842 TSER=477122460
6	1102510709.481950	172.31.189.13	10.2.168.19	GET logo.gif HTTP/1.1
7	1102510710.615038	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919518152 Ack=817110046 Win=48283 Len=0 TSV=1295244467 TSER=477123680
8	1102510710.620563	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919518152 Ack=817112742 Win=47180 Len=0 TSV=1295650717 TSER=477123680
9	1102510711.540495	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919518152 Ack=817114081 Win=48528 Len=0 TSV=1296119467 TSER=477123680
10	1102510714.531579	172.31.189.13	10.2.168.19	55284 > http [ACK] Seq=919518152 Ack=817114082 Win=48528 Len=0 TSV=1310400717 TSER=477125181
11	1102510714.780431	172.31.189.13	10.2.168.19	55284 > http [FIN, ACK] Seq=919518152 Ack=817114082 Win=48528 Len=0 TSV=1310744467 TSER=477125181

Downlink:
1	1102510696.182798	10.2.168.19	172.31.189.13	http > 55284 [SYN, ACK] Seq=817108210 Ack=919517161 Win=25612 Len=0 TSV=477122350 TSER=1281056967 WS=0 MSS=1460
2	1102510697.290116	10.2.168.19	172.31.189.13	http > 55284 [ACK] Seq=817108211 Ack=919517629 Win=25612 Len=0 TSV=477122459 TSER=1281619467
3	1102510697.328920	10.2.168.19	172.31.189.13	[TCP segment of a reassembled PDU]
4	1102510697.340860	10.2.168.19	172.31.189.13	HTTP/1.1 200 OK
5	1102510709.530317	10.2.168.19	172.31.189.13	[TCP segment of a reassembled PDU]
6	1102510709.542180	10.2.168.19	172.31.189.13	[TCP segment of a reassembled PDU]
7	1102510709.552788	10.2.168.19	172.31.189.13	[TCP segment of a reassembled PDU]
8	1102510709.563415	10.2.168.19	172.31.189.13	HTTP/1.1 200 OK
9	1102510714.529543	10.2.168.19	172.31.189.13	http > 55284 [FIN, ACK] Seq=817114081 Ack=919518152 Win=25612 Len=0 TSV=477125181 TSER=1296119467
10	1102510714.786701	10.2.168.19	172.31.189.13	http > 55284 [ACK] Seq=817114082 Ack=919518153 Win=25612 Len=0 TSV=477125350 TSER=1310744467

B) With synchronization (15.625ms accuracy)

Uplink:
No	Time			Source		Destination		Info
1	1102510696.171870	172.31.189.13	10.2.168.19		55284 > http [SYN] Seq=919517160 Win=48960 Len=0 MSS=1360 TSV=1281056967 TSER=0 WS=0
2	1102510696.290110	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919517161 Ack=817108211 Win=48960 Len=0 TSV=1281619467 TSER=477122350
3	1102510697.265620	172.31.189.13	10.2.168.19		GET index.html HTTP/1.1
4	1102510697.953120	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919517629 Ack=817108454 Win=48717 Len=0 TSV=1282978842 TSER=477122460
5	1102510698.671870	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919517629 Ack=817109801 Win=47370 Len=0 TSV=1283228842 TSER=477122460
6	1102510709.468750	172.31.189.13	10.2.168.19		GET logo.gif HTTP/1.1
7	1102510710.609370	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919518152 Ack=817110046 Win=48283 Len=0 TSV=1295244467 TSER=477123680
8	1102510710.609370	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919518152 Ack=817112742 Win=47180 Len=0 TSV=1295650717 TSER=477123680
9	1102510711.531250	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919518152 Ack=817114081 Win=48528 Len=0 TSV=1296119467 TSER=477123680
10	1102510714.531250	172.31.189.13	10.2.168.19		55284 > http [ACK] Seq=919518152 Ack=817114082 Win=48528 Len=0 TSV=1310400717 TSER=477125181
11	1102510714.765620	172.31.189.13	10.2.168.19		55284 > http [FIN, ACK] Seq=919518152 Ack=817114082 Win=48528 Len=0 TSV=1310744467 TSER=477125181

Downlink:
No	Time			Source		Destination	      Info
1	1102510696.171870	10.2.168.19		172.31.189.13	http > 55284 [SYN, ACK] Seq=817108210 Ack=919517161 Win=25612 Len=0 TSV=477122350 TSER=1281056967 WS=0 MSS=1460
2	1102510697.281250	10.2.168.19		172.31.189.13	http > 55284 [ACK] Seq=817108211 Ack=919517629 Win=25612 Len=0 TSV=477122459 TSER=1281619467
3	1102510697.328120	10.2.168.19		172.31.189.13	[TCP segment of a reassembled PDU]
4	1102510697.328120	10.2.168.19		172.31.189.13	HTTP/1.1 200 OK
5	1102510709.515620	10.2.168.19		172.31.189.13	[TCP segment of a reassembled PDU]
6	1102510709.531250	10.2.168.19		172.31.189.13	[TCP segment of a reassembled PDU]
7	1102510709.546870	10.2.168.19		172.31.189.13	[TCP segment of a reassembled PDU]
8	1102510709.562500	10.2.168.19		172.31.189.13	HTTP/1.1 200 OK
9	1102510714.515620	10.2.168.19		172.31.189.13	http > 55284 [FIN, ACK] Seq=817114081 Ack=919518152 Win=25612 Len=0 TSV=477125181 TSER=1296119467
10	1102510714.781250	10.2.168.19		172.31.189.13	http > 55284 [ACK] Seq=817114082 Ack=919518153 Win=25612 Len=0 TSV=477125350 TSER=1310744467














 

-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Lee Riemer
Sent: Thursday, January 14, 2010 21:40
To: wireshark-users@xxxxxxxxxxxxx
Subject: Re: [Wireshark-users] Timestamp Skew

Thanks for the link!  I may do this or disable one of the cores.

On 1/14/2010 2:33 PM, Gianluca Varenni wrote:
> Well, you already got an answer from the WinPcap team... I work in the 
> WinPcap team.
>
> If a timestamp precision in the order of some milliseconds is ok for 
> you, then you can switch the timestamping mode to a less precise one 
> that is sync'ed with the system time. You can find details on how to 
> change the timestamping mode in this email:
>
> http://www.winpcap.org/pipermail/winpcap-bugs/2010-January/001153.html
>
> Have a nice day
> GV
>
>
>
> --------------------------------------------------
> From: "Lee Riemer"<lriemer@xxxxxxxxxxxx>
> Sent: Thursday, January 14, 2010 11:28 AM 
> To:<wireshark-users@xxxxxxxxxxxxx>
> Subject: Re: [Wireshark-users] Timestamp Skew
>
>    
>> Thanks all for the info.  I'll direct my concerns to  the WinPcap group.
>>
>> On 1/14/2010 12:57 PM, Gianluca Varenni wrote:
>>      
>>> WinPcap synchronizes with the system time only when at the beginning 
>>> of a capture. More precisely, it syncs when you start a capture only 
>>> if there are no other captures (on the same adapter or different 
>>> adapters) running. As a consequence, adjustments to the clock done 
>>> by NTP are not seen.
>>>
>>> Have a nice day
>>> GV
>>>
>>> --------------------------------------------------
>>> From: "Guy Harris"<guy@xxxxxxxxxxxx>
>>> Sent: Thursday, January 14, 2010 10:25 AM
>>> To: "Community support list for 
>>> Wireshark"<wireshark-users@xxxxxxxxxxxxx>
>>> Subject: Re: [Wireshark-users] Timestamp Skew
>>>
>>>
>>>        
>>>> On Jan 14, 2010, at 10:19 AM, Lee Riemer wrote:
>>>>
>>>>
>>>>          
>>>>> The sniffer server is syncing with NTP, and this is also a dual 
>>>>> core system.  You may be on to something, though.  If the box is 
>>>>> correcting it's skew with NTP, wireshark might not be if it isn't 
>>>>> polling the time for each packet.
>>>>>
>>>>> Anyone know exactly how WS picks the time to stamp?
>>>>>
>>>>>            
>>>> On Windows, it takes it from the information supplied to it by 
>>>> WinPcap, so it's not Wireshark that's picking the time to stamp, 
>>>> it's WinPcap.  (On UN*X, it takes it from the information supplied 
>>>> to it by libpcap, which is, on almost all platforms, the time 
>>>> supplied to libpcap by the OS-native packet capture mechanism being 
>>>> used by libpcap.)
>>>>
>>>> If none of the WinPcap developers reply here, you might want to 
>>>> report it to them as a bug:
>>>>
>>>> http://www.winpcap.org/bugs.htm
>>>> ___________________________________________________________________________
>>>> Sent via:    Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
>>>> Archives:    http://www.wireshark.org/lists/wireshark-users
>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>>
>>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>
>>>>          
>>> ___________________________________________________________________________
>>> Sent via:    Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
>>> Archives:    http://www.wireshark.org/lists/wireshark-users
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>
>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>
>>>        
>> ___________________________________________________________________________
>> Sent via:    Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>
>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>      
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>               
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>    
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe