BPF Lexer coverage

[mosajjal]

Hi,

randomly came across this one. Awesome stuff! Wondering how complete is your BPF filter lexer? Happy to bring it to gopacket/gopacket and further remove some dependencies on CGO over there if you're keen to cover all options offered by tcpdump.

Cheers,
Ali

[deitch]

Welcome @mosajjal

Awesome stuff!

Thanks. It was needed for something a few years back, and necessity being the mother of invention and all that...

Wondering how complete is your BPF filter lexer?

Probably nowhere near enough. You can follow it through from NewExpression() and down from there.

Happy to bring it to gopacket/gopacket and further remove some dependencies on CGO over there if you're keen to cover all options offered by tcpdump.

Always keen to expand. What did you mean by "bring it to gopacket/gopacket"? We actually use gopacket/gopacket in various places for structures and the like.

I see you contributed to gopacket/gopacket?

[mosajjal]

Thanks for the intro mate. for context, I maintain gopacket/gopacket nowadays and for years I wanted a pure Go implementation of the lexer implemented (google/gopacket#851). Now that you've started the process, keen to draft a PR and see if we can work together to move the lexer from libpcap to pure Go. I think this sitting under gopacket will help a lot of people who want to manage packets but don't want to include libpcap in the binary.

[deitch]

I maintain gopacket/gopacket nowadays

Ah, that explains it. Funny, this proj used to depend on google/go-packet, and @amarcum kindly opened #53 to use the more up-to-date gopacket just a few weeks ago.

Now that you've started the process, keen to draft a PR and see if we can work together to move the lexer from libpcap to pure Go. I think this sitting under gopacket will help a lot of people who want to manage packets but don't want to include libpcap in the binary

You want to merge the functionality into gopacket? Sure, I am up for that. gopacket is pretty solid. More than a few times, people have come to this after saying, "we wanted to use gopacket but it required CGO and libpcap, so we didn't.

As long as we have the same functionality, and the ability to compile without CGO. I don't mind if there are different packages, one with CGO and one without, especially if there is a functionality gap, as long as the option to do pure go always works without dependencies. I run this on macOS at times, sometimes other interesting platforms.

[mosajjal]

yeah I think it'd be good to merge that function into gopacket. since the lexer is not complete yet, we can find a home for it under pcapgosub directory so this function and the original libpcap one can co-exist.

[deitch]

Sounds like a plan. Maybe call it go-pcap though, instead of pcapgo, so it gets imported as pcap? That is why I named it as I did.