We have a stange issue which is likely related to a NIC or TCP stack. A better understanding of where exactly wireshark captures an outgoing packet (and what PC related fucntions may still remain) would be very helpful in isolating this issue.
In our case we have a host PC connected through a nTAP aggregator to our product (a load) Wireshark is running on both the host PC and Wireshark is connected to a sniffer PC connected to the aggregator.
We send the following sequence of UDP packets between the host and load.
Packet 1: UDP (82 bytes) Host -> Load
Packet 2: UDP (79 bytes) Load -> Host
Packet 3: UDP (87 bytes) Host -> Load
Packet 4: UDP (78 bytes) Load -> Host
Repeat starting with Packet 1 until the sequence takes > 90mS.
Typically the sequence completes in ~2ms however when it is delayed it can see interpacket delays of ~10 - 110mS. As described above, When this sequence fails, the inter-packet delay is generally 95~105mS delayed.
We see on the Host PC wireshark that the delay is between packet 1 and 2 whereas we see on the sniffer PC that the delay is between packet 4 and 1 (next sequence)
Any suggestions as to where the outgoing packet may have been generated, seen by wireshark, but not actually transmitted on the wire would be very helpful.
Host PC is a Lenovo T420i with a gigabit (wired) lan connection.
_ Update _
I used Python to emulate this same behaviour with the following sequence.
def beat(j,k): for i in range(0,k): d = 1 a = time.clock() foo = s.sendto(mes, (ip,po) ) b = time.clock()
beat(10,100000) oops: 164.827757197 164.900906969 164.900928408 0.0731712110398 2014-07-17 13:37:12.552000 oops: 174.882007838 174.896305127 174.896343092 0.0143352542291 2014-07-17 13:37:22.498000 oops: 218.296230804 218.38277295 218.38279439 0.0865635856404 2014-07-17 13:38:05.997000 oops: 259.240381154 259.340393392 259.340411258 0.100030104257 2014-07-17 13:38:46.997000
this shows that the output packet message is often prevented from finishing. with as much as 100mS in the call to send the packet ... Wireshark receives the packet in its capture immediately.
It is not clear why the call is taking very long or why wireshark is able to see this packet before the command finishes executing.
This has been verified in LabVIEW, C#, and Python at this point.
asked 17 Jul '14, 09:46
edited 17 Jul '14, 13:48
Wireshark doesn't timestamp packets; it relies on libpcap/WinPcap to provide timestamped packets.
In most cases, libpcap relies on the OS's native packet capture mechanism to timestamp packets (HP-UX is the only exception), and WinPcap's in-kernel driver does the timestamping on Windows.
For outgoing packets, the packets are timestamped by the capture mechanism (for most UN*Xes - the code that reads the packets timestamps them on HP-UX) or by the in-kernel driver (on Windows). That code usually timestamps the packets, and hands a copy up to its client (libpcap/userland WinPcap), before the packet is transmitted, and possibly even before it's handed to the network device driver.
So the packet timestamp for outgoing packets will probably be a time before the packet is put onto the wire (and the packet might not even make it onto the wire if, for example, you're sending on half-duplex Ethernet and you keep getting blocked by carrier being up or keep getting collisions).
answered 17 Jul '14, 14:36
Guy Harris ♦♦