-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove custom libpcap / gopacket dependency #34
Comments
Alternatively, we could consider / try switching to AF_PACKET (as demonstrated here). This removes the libpcap dependency, and according to this post, we should be able to listen on the any interface and still be able to extract the interface name for each packet. Might be worth taking a look at. Note: Only works under Linux, but we could keep the current implementation for other OSes and replace it for Linux (which is probably the most prevalent use case anyway). |
We should definitely explore this. While I don't know what happens performance wise on hosts with many interfaces if we double the amount of go routines, a benefit coming out of the 1 routine per direction approach is that the direction heuristic doesn't have to be applied with every packet, but rather as part of the write-out preparation every 5 minutes. Might be relevant performance wise. |
On it already, I've already switched Linux to AF_PACKET, except for the linked issue (which is not really related to that) it works like a charm. The split for all non-Linux OSes is the next thing I'll look into. As background: Right now my idea would not be to keep two independent capture paths and then merge on writeout but rather wrap the capturing in a Go interface (partly done for AF_PACKET anyway) and merge the packets right when they appear. That way, the whole flow logic can remain as is... But I'll have to see if that pans out :-P |
It probably depends on how far you're drilling into the capture part already. If it's a small addition and GPFlow remains untouched, it's definitely easier to get started the way you are implementing it right now. I'd have to check whether the map lookups have any significant performance implication. If so, doing it every 5 minutes would be prudent. If not, we can keep it the way it is. That being said: if we introduce additional map checks for the UDP tracking, it might be interesting to think about in any case. |
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
We should consider options to get rid of the custom built static libpcap / gopacket dependency in favor of simply using the vanilla gopacket library. As a workaround to the
incoming
/outgoing
flag provided via the custom library we could split up capturing for each interface into two goroutines, each limiting traffic via BPF filter to either incoming or outgoing. Consequently, capturing must (opaquely) "duplicate" each interface and finally merge the results into combined flows.The text was updated successfully, but these errors were encountered: