I'm developing a program which uses the pcap library in C and currently running it on my mac. The program is hanging around 1.3Mb of memory usage based on the Activity Monitor. I've tested it as well and it seems that around 900Kb - 1.0Mb are purely from creating/activating a pcap handle (i.e I have no control over it except maybe the internal buffer?).
Now that isn't a large amount but eventually I want to port this over to a new program for a flipper zero I ordered (whitehat purposes). The specs for the flipper zero say it has around 256Kb of memory so I'm concerned this application will crash it.
I come from a web development background so I'm not super familiar with how my OS is affecting memory usage etc. Is the large memory usage on my PC due to the MacOS or pcap will run at 1Mb of memory usage on the flipper zero as well?
Is there anything I can do in this situation? Are there ways to limit the memory usage of pcap, alternatives etc? Or is this just because the Mac has more resources so it's allocating more.
Physical footprint: 1233K
Physical footprint (peak): 1233K
Idle exit: untracked
On BSD systems - CupertinoBSD :-) is one such system - current versions of libpcap request a 512KB kernel buffer; as the BPF capture mechanism, which is what those systems use for packet capture, is double-buffered, that means 1MB of kernel buffer.
That should not show up as part of the address space of the process, as it's a purely kernel-space buffer.
However, a 512KB buffer in the kernel must be read, into its entirety, into a user-space buffer, so libpcap also has to allocate a 512KB user-space buffer. That will show up as part of the address space of the process.
The Flipper Zero Wikipedia page indicates that it runs FreeRTOS; that, plus the microcontroller being a M-profile Arm processor, suggests there's no virtual memory, meaning that if the user-mode buffer won't fit in physical memory, either 1) libpcap will fail if you try to open a capture device with a buffer of that size or 2) it will crash.
It also means that, to run a libpcap-based application, somebody must have ported libpcap to it; hopefully, if they've done so, they'll arrange that a too-large buffer will cause a libpcap failure rather than a crash.
It also means that it may or may not have a capture mechanism similar to the BSD BPF capture mechanism, so the behavior on macOS may, or may not, apply here.
And, by default, it should ask for a capture buffer small enough to fit in physical memory, so that it won't fail by default.
tl;dr - your program, if you build it as a Flipper Zero application, will probably not ask, on the Flipper Zero, for a buffer as large as it does on macOS, so this should not be an issue (unless you're using
pcap_create()/pcap_set_buffer_size()/pcap_activate(), in which case don't usepcap_set_buffer_size(), just let the system choose a buffer size for you).