On Tue, Feb 6, 2018 at 8:39 AM, S. Jacobi <[email protected]> wrote: > We have a sender who send packets, each one gets a 16bit number. This > number, I will call it packet ID, is strictly ascending, but starts > again from zero if the 16bit range is reached. > Then, the sender distributes the packet on multiple interfaces and we > cannot make any assumptions how this is done. Packet IDs can appear > arbitrarily on the interfaces, packet IDs can be reordered (although > only in a very limited range), and packets need not be (and in fact are > not) evenly divided onto the interfaces. > On the receiving > Our own capturing tool is rather simple. It spawns a thread for each > interface, and the thread functions tries to read and process each > incoming packet as fast as possible. This leads to the problem that if > one interface receives more packets, the packet IDs read from different > interfaces drift further apart, even going one full circle and so on > and on. > However, if we use tshark to capture from all interfaces and save the > output to a file, the process this file with our tool, everything works > fine. > So, tshark needs to have some sort of synchronisation mechanism, to > fairly distribute the reads from each interface. The packet timestamps > in the capture file are not always ascending, there are a few jumps in > it. > I wasn't able to spot this mechanism in the code, so I'm grateful for > any information on this.
As far as I am aware it is the kernel that is doing this. Also, I believe that only Linux supports the any device. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
