On Tue, 6 Feb 2018 10:31:38 -0800
Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Feb 6, 2018, at 9:20 AM, Richard Sharpe
> <realrichardsharpe@xxxxxxxxx> wrote:
>
> > On Tue, Feb 6, 2018 at 9:07 AM, S. Jacobi
> > <sjacobi@xxxxxxxxxxxxxxxx> wrote:
> >> On Tue, 6 Feb 2018 09:05:14 -0800
> >> Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
> >>
> >>> 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.
> >
> > I have not looked at the code, but I suspect that it is something
> > like this:
> >
> > https://stackoverflow.com/questions/37294540/binding-the-af-packet-socket-to-all-interfaces
> >
> > That is, the kernel is doing it.
>
> That's how the "any" device is implemented by libpcap, so that's what
> happens if you capture on the "any" device.
>
> However, if, in Wireshark or TShark or dumpcap, you capture from an
> explicitly specified list of interfaces containing more than one
> interface, there are multiple pcap_t's open, and packets are
> separately received from all of those pcap_t's and those are written
> to a single capture file.
>
> So if they aren't in timestamp order when you explicitly capture on
> more than one interface, that's dumpcap's fault (which means it's the
> fault of "Wireshark", in the sense of the entire Wireshark release,
> as dumpcap is the program that does the packet capturing for
> Wireshark and TShark), not the fault of the OS kernel.
The packets out-of-timestamp-order are quite rare and always between
two interfaces. It could be that dumpcap tries to put them in the
correct order but fails to do so when one interface lags behind. Thanks
for your answers anyway.