Re: Multiple interface capture and thread safety

[Wiener Schnitzel <wiener.schnitzel () still-pending com>]

On 11.05.2012 09:02, Guy Harris wrote:
> On May 10, 2012, at 7:43 AM, Wiener Schnitzel wrote:
>
> > I need to perform packet sniffing on several interfaces at the same 
> > time.
>
> Are you processing packets from each interface independently, so that
> a packet on interface A is not looked at when processing packets from
> interface B, or are you processing the packets from all of the
> interfaces as a single stream, so that you need to see packets from
> multiple interfaces in order?

At a certain point, I'd like to treat the packets as they came from a 
single source.


> Even if you're sniffing on *one* interface, I think that, with at
> least some versions of the Linux kernel, "as it gets to the
> interfaces" and "as it gets delivered to the PF_PACKET socket from
> which libpcap reads" are not necessarily the same thing on multi-core
> machines.  I seem to remember that some people have seen packets with
> out-of-order timestamps, and have the impression that the problem is
> that if two packets are processed on different cores, the packet that
> arrived second might be queued up on the socket before the packet 
> that
> arrived first if, for whatever reason, the thread on the second core
> manages to get its job done faster.  I don't know whether this is
> still a problem with reasonably recent versions of the kernel.

I'd would be very interested in this kind of details. Do you think it 
is documented somewhere ?
Also, does that mean that PCAP timestamps are normally reliable (if the 
NIC cannot expose its own RX timestamp) ?



> Now, if you put all the pcap_t's into non-blocking mode, and pass a
> count of 1 to pcap_dispatch(), so it processes only one packet, or if
> you use pcap_next() or pcap_next_ex(), you could try reading from 
> each
> of the interfaces, process the packet with the lowest time stamp, 
> and,
> in the next trip through the loop, read another packet from the
> interface from which the packet you processed came and re-check the
> packets read previously from the other interfaces, you'd process the
> packets in time stamp order (modulo any out-of-order delivery from 
> the
> kernel on any single interface).

Nice suggestion.


> If each thread is processing packets independently, so that you don't
> have to worry about processing packets from multiple interfaces in 
> the
> right order for all of those interfaces, then you could do it in one
> thread - for each call to pcap_dispatch(), do the processing for
> packets from the interface in question.  Doing it in multiple threads
> would make better use of multiple cores in your application, however.
>
> If that's *not* the case, doing the capture in different threads
> still requires some scheme to process packets from different
> interfaces in order.

I see. As I said, I might need to merge the data coming from the 
interfaces, so I need an algorithm to compare
the age of packets with different sources.


> pcap_compile() uses YACC and Lex, or uses replacements thereof in
> YACC-compatible/Lex-compatible mode, so they're *not* thread safe -
> the lexical analyzer and parser have non-thread-safe state.
> pcap_setfilter(), however, should be thread-safe, and the rest of the
> APIs are thread-safe as long as any given pcap_t is only being
> processed in one thread at a time;

Hence, if each thread wants to compile a different BPF, I need an 
external lock to the function. Otherwise, I can compile a shared BPF in 
the main thread and set it in the sniffing threads without any issues. 
Am I right ?

Thanks


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.