Additionally the Windows installers have an extra component: a preview of the upcoming user interface for Wireshark 2.0. The following features are new (or have been significantly updated) since version 1.11.3: Transport name resolution is now disabled by default. Support has been added for all versions of the DCBx protocol. Note: for this example I used dns.qry.name which is defined since Wireshark version 0.10.9. Supposing you have a mate plugin already installed you can test it with the current Wireshark version. A Gop for DNS requests First we'll tell MATE how to create a Gop for each DNS request/response. MATE needs to know what makes a DNS PDU.
Good day, forum.
This is my first post, and I did try to find the answer before posting. Nothing did come up close to what I am looking for.
I am running a packet capture on my WAN interface facing the ISP. I collect just the upstream traffic (my LAN towards the ISP) and then export collected packets into CSV for calculation purposes. The capture is performed on pfSense running on dedicated hardware (Intel Xeon platform, pfSense running on bare metal). Capture is done on 1GE interface.
In the CSV, I have column with packet timestamp and packet size. I calculate the inter-packet gap, by subtracting arrival time of packet N+1 from arrival time of packet N. I get Tdelta value, in second.
Next, assuming that the packet arrival time is the time at the end of the packet (when the packet was received and processed by kernel), I calculate idle time between packet N+1 and N, using simple formula: Tdelta - Psize * 8 / 1e9. Psize is packet size in bytes, 1e9 is due to 1GE Ethernet line rate (10^9 bps at L2).
And here is the problem - in some situations, I am getting negative packet gap (shown as 5th column below) and it is not clear to me what the problem is. The capture machine has more than enough CPU time to do the capture right (CPU idles at 3%, even at capture time), the system is on SSD, so it should not have problems writing data into file, and there is enough free memory to store the capture many times over.
Columns above are: (1) packet number, (2) packet timestamp from wireshark, (3) TDelta, (4) Tdelta - Psize * 8 / 1e9, (5) value of (4) in ms, (6) value of (4) in byte times, and (7) packet size.
Wireshark 10.9 Download
I do not see the same issue in captures under Windows OS, but I want to preserve all packet fields and VLAN information, which requires me to push for Linux-based capture
Thank you in advance for any hints.
Comments
I doubt you can get accurate numbers unless you have some hardware timestamping capture hardware in there.
I have sniffers that can capture at full port speed, but never check the timing between frames. The advantage of a sniffer, it can capture packets with a short IFG (it is permitted per 802.3 spec). I haven't any luck with computers because usually they can read, and write fast enough. If there isn't a lot of data, an Oscope will accurately capture the IFG (bits and time).
Thank you for the feedback. Do you know if the use of dedicated hardware capture cards (Napatech NT4E-4-STD, for example) help with the timestamps, i.e., whether these do hardware timestamps?
Wireshark 1.9
I have confirmation that Napatech cards will do ns precision hardware timestamping, so I will get one, and confirm whether the issue is gone then. I will update the chain as I learn more.