network_monitor broken in linux

[tbearden]

When I use network monitor on my kubuntu precise machine, the network_monitor starts and waits for a connection and then exits immediately when it gets one. Traced this back to line 181 of the script "self.pcap = pcapy.open_live(self.device, -1, 1, 100)". Trying this just in a shell I get an error "pcapy.PcapError: eth0: can't allocate oneshot buffer: Cannot allocate memory". Changing line 181 to "self.pcap = pcapy.open_live(self.device, 1518, 1, 100)" fixes this, but I haven't tested on windows, so I don't know if it breaks anything there.

[Fitblip]

Hrm, that's odd.

How much memory do you have on your box? Is it a server or a desktop? I've never seen that issue myself, but changing that shouldn't break anything, just sets a static allocation buffer to capture packets in on.

My only concern is capturing larger requests, so what happens if you set it to say 65535 (so large it doesn't matter)?

[tbearden]

I am on a 32-bit system with 4GB of mem.

[tbearden]

setting it to 65535 seems to work also.

[Fitblip]

That's quite odd, I'll mess with it tonight and make sure it doesn't break anything before merging into master. I assume you're using the most up-to-date everything?

[tbearden]

yep, cloned on Oct 11.

[tbearden]

my pcapy is from the ubuntu repository and is version 0.10.8-1build1.

[jtpereyda]

It also only seemed to happen on Linux for me.

@tbearden correctly identified that the second argument to open_live (snaplen) is the problem.

From pcapy docs:

snaplen specifies the maximum number of bytes to capture.

After some digging I found this bug report: the-tcpdump-group/libpcap#99 where someone says:

Most likely older versions of libpcap treated -1 as a very large unsigned integer and did not detect the memory allocation failure. Now that bug in the library is fixed and the bug in the application is visible better.

TL;DR

giving -1 to open_live's second argument is some kind of pcap library hack and not officially supported, and therefore breaks in some instances.

Solution

Change the -1 to some large positive integer. The maximum 32 bit integer (2,147,483,647) value should do what -1 was doing before, but lots of people online seem to use 65,535. 2 gigs seems like a lot for a packet anyway.

I'm out of time tonight but maybe I can do this soon. The fix is simple anyway.