Remove custom libpcap / gopacket dependency

[fako1024]

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.

[fako1024]

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

[els0r]

Consequently, capturing must (opaquely) "duplicate" each interface and finally merge the results into combined flows.

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.

[fako1024]

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

[els0r]

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.