-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropped packets when capturing from multiple interfaces #1220
Comments
Since you mention I also wonder if the immediate delivery mode and the buffer size are factors here. |
Its all single-threaded. It uses a separate capture for each interface, kicks off the processes which will generate the traffic, sleeps to let things settle and then reads in each capture's buffer with
That sounds like it could be relevant, weird that it doesn't seem to affect all the capture interfaces at a time but I'll do some testing with it tonight. |
Presumably means it opens a separate
Does this mean it does something such as
i.e., that it proceeds sequentially through all the interfaces, processing them one at a time? |
@guyharris yes to both |
Libpcap doesn't guarantee that will work. In particular, the What you should do is, first, to put all of the Then, do something such as (C-style pseudo-code):
|
@infrastation thanks for the pointer, it was the immediate delivery mode. I patched a call to @guyharris what doesn't libpcap guarantee here? The capture is already in non-blocking mode so that isn't a problem, and the buffer is more than large enough to accomodate the whole capture. |
[UPDATED: fixed the last sentence to say
There's a tradeoff between immediate and non-immediate mode. Immediate mode delivers packets immediately, so you get one wakeup per packet, so that's one system call per packet and, in systems where packet data is copied from the kernel to userland (Linux isn't such a system unless you have a really really old kernel and an old version of libpcap), that's one kernel-to-user copy per packet. Without immediate mode, packets can be delivered in batches, with one wakeup and one system call (and, without memory-mapped capture, one copy) per batch, which is more efficient. This means that running in immediate mode could increase the chances of packet drops if you're getting high traffic.
In other words, you've called, for each of the capture handles, whatever Net::Pcap call results in calling |
I'm having issues with capturing from multiple devices in the same process using libpcap on Linux.
Unfortunately I haven't been able to reduce this to a simple test case - I can only reproduce it as part of a big regression test suite for some other software, but as far as I've been able to figure out, when pcap (via the Net::Pcap Perl module) is opened on multiple devices concurrently, not all of the captures actually receive packets.
This was introduced in libpcap 1.5.0 and is still present on master, specifically this commit:
So I'm not really sure where the problem is - whether its the TPACKET_V3 support in the kernel, the TPACKET_V3 support in libpcap or some other behaviour in the library that was changed by the same commit.
I'm hoping someone more familiar with pcap might know what's happening here. Happy to test any patches/theories.
The text was updated successfully, but these errors were encountered: