[NETFRAME] Net::Packet::Dump / Net::Frame::Dump::Online - Concurrent Simultaneous Capture Limit?

[Darien Kindlund]

Hi GomoR,

Thanks for getting back to me.

> There is no limitation on the number of object instances you can
> create. If there is a limitation, it has more to do with libpcap,
> specifically the number of /dev/bpf* devices you may have. But
> it depends upon your operating system, and you did not gave me this
> information.

The operating system I'm using is: Linux Ubuntu 8.04.2
Specific kernel is: 2.6.24-23-server #1 SMP Mon Jan 26 00:55:21 UTC
2009 i686 GNU/Linux

If you happen to know of a limitation for this OS, please let me know.
I tried searching for any corresponding /dev/bpf* devices on the
system, but I couldn't find any references.

> I suggest you to rewrite your program with Net::Frame::Dump::Online
> instead. Then test, and go back to me.

Okay, I'll go ahead with the rewrite.  Here's a crystal clear idea of
what I'm trying to accomplish:

Let's say you have this perl code running on a linux router that's
networked to 50 other systems on a local Class-C subnet.  All network
traffic from 50 systems go through your router.  As such, I'm trying
to create individual .pcap files, based upon the source MAC addresses
of each of the 50 systems.  More importantly, these .pcap files have
to capture packets for a specific period of time -- so I can't just
let the .pcap file grow indefinately.

So, as such, my first attempt was creating 50 individual
Net::Packet::Dump sessions -- realizing that this indirectly creates
50 different forked processes.  I noticed that the
Net::Packet::Dump::_startTcpdump() function is almost identical to
Net::Frame::Dump::Online_startTcpdump(), so I'm guessing
Net::Frame::Dump::Online will have the same issue -- creating 50
forked processes.  Assuming I have the CPU and RAM hardware to handle
this, I didn't know if there were any other limitations.

My other thought would be to simply create a single
Net::Frame::Dump::Online session, and somehow register 50 different
callback handlers, where each handler writes a different .pcap, based
upon the source MAC address of one of the systems.  The great benefit
of this approach is that we can reuse a single (long running) forked
process.  However, the problems with this approach are:

1) It looks like Net::Frame::Dump::Online only supports a single
callback handler -- there may be a limitation with how many
simultaneous handlers Net::Pcap::loop() can support.  Plus, the 50
systems' source MAC addresses can change, so we need a way to
dynamically update the callbacks and let them know the new source MAC
addresses to look for -- that might not be so easy, as it could be
simpler to tear down individual forked processes.
2) It's not easy to filter by source MAC address from within perl,
using the Net::Frame code (it's possible, but probably certainly
slower than using libpcap's built in filters).
3) Inside any of the callback code, even if we get a corresponding
Net::Frame::Simple object, which holds our matching packet (based on
source MAC address), it's not clear to me how I could easily write
that packet out to a .pcap file using Net::Frame::Dump::Writer.

So, as I said, I'll try the Net::Frame::Dump::Online rewrite and let
you know if I have any problems.  The code I'm working on is
open-source, so once I finish the rewrite, I can give you a URL to the
codebase, so you can check it out.

Regards,
-- Darien