On Tue, 6 Feb 2018 09:05:14 -0800
Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
> On Tue, Feb 6, 2018 at 8:39 AM, S. Jacobi <sjacobi@xxxxxxxxxxxxxxxx>
> 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.
>
We are on Linux, yes, but we don't capture from any. tshark allows to
specify multiple interfaces.