network_monitor broken in linux

Question

network_monitor broken in linux

tbearden opened this issue 12 years ago · 7 comments

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.

Answer 1 · 2012-10-23T18:28:36.000Z

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)?

Answer 2 · 2012-10-23T19:02:52.000Z

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

Answer 3 · 2012-10-23T19:18:25.000Z

setting it to 65535 seems to work also.

Answer 4 · 2012-10-24T15:17:25.000Z

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?

Answer 5 · 2012-10-24T15:48:53.000Z

yep, cloned on Oct 11.

Answer 6 · 2012-10-24T15:50:22.000Z

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

Answer 7 · 2015-08-14T00:23:35.000Z

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.