https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3815
--- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx> 2009-08-07 17:48:09 PDT ---
I.e., you're capturing traffic that's being routed through the machine on which
you're running Wireshark (so that the packets are being received on the
receiver interface card, passed through the Windows networking stack, and sent
one hop closer to the destination machine on the sender interface card)?
Is your machine a multi-core machine (multiple processor cores on one chip) or
multi-processor machine (multiple processor cores on more than one chip)? If
so, I don't know whether the Windows networking stack would work this way, but
it's conceivable that it could be handing the packet to the WinPcap kernel
driver on one core and to the IP routing code on another core, and that the
thread running on the latter core could hand the packet to the WinPcap kernel
driver as a *transmitted* packet before the thread running on the former core
hands it to the WinPcap kernel driver as a received packet. If so, that would
cause the symptoms you're seeing.
Yes, this means that the receiver time stamp does *not* reflect the time at
which the entire Windows networking stack (including the add-on WinPcap driver)
first sees the received packet. If your forwarding-delay calculations depend
on that being the case, you might have to find some other way of getting the
time stamps (and it might involve getting the source code to the kernel NDIS
code, or the driver for the network interface drivers, and modifying *them* to
do the time stamping; good luck with that...).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.