Question

this is my first question here @stackoverflow.

I’m writing a monitoring tool for some VoIP production servers, particularly a sniff tool that allows to capture all traffic (VoIP calls) that match a given pattern using pcap library in Perl.

I cannot use poor selective filters like e.g. “udp” and then do all the filtering in my app’s code, because that would involve too much traffic and the kernel wouldn’t cope reporting packet loss.

What I do then is to iteratively build the more selective filter possible during the capture. At the beginning I capture only (all) SIP signalling traffic and IP fragments (the pattern match has to be done at application level in any case) then when I find some information about RTP into SIP packets, I add ‘or’ clauses to the actual filter-string with specific IP and PORT and re-set the filter with setfilter().

So basically something like this:

1. Initial filter : “(udp and port 5060) or (udp and ip[6:2] & 0x1fff != 0)” -> captures all SIP traffic and IP fragments

2. Updated filter : “(udp and port 5060) or (udp and ip[6:2] & 0x1fff != 0) or (host IP and port PORT)” -> Captures also the RTP on specific IP,PORT

3. Updated filter : “(udp and port 5060) or (udp and ip[6:2] & 0x1fff != 0) or (host IP and port PORT) or (host IP2 and port PORT2)” -> Captures a second RTP stream as well

And so on.

This works quite well, as I’m able to get the ‘real’ packet loss of RTP streams for monitoring purposes, whereas with a poor selective filter version of my tool, the RTP packet loss percentage wasn’t reliable because there was some packets missing due to packet drop by kernel.

But let’s get to the drawback of this approach.

Calling setfilter() while capturing involves the fact that libpcap drops packets received “while changing the filter” as stated in code comments for function set_kernel_filter() into pcap-linux.c (checked libpcap version 0.9 and 1.1).

So what happens is that when I call setfilter() and some packets arrive IP-fragmented, I do loose some fragments, and this is not reported by libpcap statistics at the end: I spotted it digging into traces.

Now, I understand the reason why this action is done by libpcap, but in my case I definitely need not to have any packet drop (I don’t care about getting some unrelated traffic).

Would you have any idea on how to solve this problem that is not modifying libpcap’s code?

Answer 1

What about starting up a new process with the more specific filter. You could have two parallel pcap captures going at once. After some time (or checking that both received the same packets) you could stop the original.