-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Brief description
The timestamp of Pcap or PcapNG files read using rdpcap() are interpreted differently to Wireshark.
Environment
Scapy Version: 2.4.3.dev170
Python: 3.7.5
OS: Kali 2019.4 (Linux kali 5.3.0-kali2-amd64 #1 SMP Debian 5.3.9-3kali1 (2019-11-20) x86_64 GNU/Linux)
Wireshark: 3.0.5-1on Linux
Cross-checked timestamp on Windows with Wireshark 3.0.6-0
ProfiShark Manager: 2.5.54
How to reproduce
Open a Pcap or PcapNG file of your choice with data in nanosecond resolution.
To reproduce the 10³ factor error you need a capture from ProfiTAP's ProfiShark.
Example view in Wireshark:
Plain text timestamp: 2019-11-15 15:00:16.444223380
Code used in Scapy:
pcap = rdpcap('c1.pcapng', 1)
for p in pcap:
print(p.time)
Actual result
Output displayed:
1573830016444.2234
Adding some formatter:
pcap = rdpcap('c1.pcapng', 1)
for p in pcap:
print(p.time)
print(p.time/1000)
print('%.9f' % (p.time/1000))
Results:
1573830016444.2234
1573830016.4442234
1573830016.444223404
Actual problems:
- Timestamp is wrong by factor 10³ (only from ProfiShark files)
- Timestamp is wrong by 24 ns
Expected result
I expected to get exactly the same timestamp as seen in Wireshark.
Related information
Changing read_packet
in utils.py
p.time = float((tshigh << 32) + tslow) / tsresol
to
p.time = Decimal((tshigh << 32) + tslow) / tsresol
seem to resolve the conversion problem.
Printing the options = block[16:]
variable in read_block_idb
looks like the following.
Wireshark saved capture:
b'\t\x00\x01\x00\t\x00\x00\x00\x0c\x00\x17\x00Linux 5.3.0-kali2-amd64\x00\x00\x00\x00\x00'
ProfiShark saved capture:
b'\x00\x00\x00\x00'
b'\x00\x00\x00\x00'
b'\x00\x00\x00\x00'
b'\x00\x00\x00\x00'
I think this leads to the default value of tsresol = 1000000
.
I don't know if ProfiShark breaks the PcapNG format here or if it's a Scapy issue. Nevertheless, Wireshark does not have any problem to open the ProfiShark files.