[WIP] Support for other capture options #36
Conversation
…hes like af_packet
…forcing libpcap via force_pcap built tag
|
@els0r FYI: Still WIP (next would be the bidirectional pcap capture), but the recent commit replaces PCAP by AF_PACKET for Linux completely. I did a quick run locally for comparison, accumulated CPU usage goes down by >30% while yielding the same output: |
|
Wow! That sounds like we're on to something 😁. Is the comparison between a If so, do you know how it compares to the standard capture without ZeroCopy? |
|
Concerning BPF: I had the fleeting idea that we could write the BPF code generator ourselves based on pcap_compile. After reading through the function, I discarded that idea very quickly 🙃 No idea how to get around the CGO dependency on this one to be honest. |
|
@fako1024 : FYI. Taking a shot at removing the custom libcap. And if Apple auto-corrects this to lieb-pcap one more time, I’ll scream so loud that Steve Jobs will hear it… |
First steps towards using the standard libpcap library. At the moment, it relies on BPF filters "inbound" and "outbound". The current code is _not_ stable, since it fails when running on MacOS, where apparently, the BPF filters aren't supported.
Do not rely on BPF, but rather on `handle.SetDirection`, which, ironically also fails on MacOS. Currently uses `ReadPacketData` instead of `ZeroCopyReadPacketData` due to inconsistencies observed with goProbe's stable version. Also removes the fako1024 gopacket fork dependencies everywhere except for the afpacket case
| PcapMutex.Unlock() | ||
| return fmt.Errorf("Interface '%s': failed to set bpf filter to %q: %w", iface, bpfFilter, err) | ||
| } | ||
| err = ds.handle.SetDirection(ds.direction) |
There was a problem hiding this comment.
Craps out on MacOS for Outbound traffic:
[ ERR] Wed Jan 11 14:58:32 2023 Interface 'en0': failed to set direction to OUTBOUND: Generic error
There was a problem hiding this comment.
Ooof. Didn't see that coming. Does tcpdump on MacOS support that? As in: Is that just something that the Go implementation lacks in feature or is a fundamental libpcap limitation on MacOS?
|
@fako1024 : here's my shot at the direction split for pcap. The traffic patterns align, see comment about Finally, we should have a discussion whether it makes sense to support MacOS altogether. Having to maintain both OS'es, which may be UNIX, but behave vastly different on several levels (especially once CGO is involved) seems more pain than gain. Could be worth to shift focus to Linux again. |
|
Preliminary results for This puts |
This PR is not yet ready to merge, it's supposed to prepare features for more capture flexibility (standard libpcap, PF_RING, AF_PACKET, ...).