https://github.com/brimdata/brimcap/issues/19#issuecomment-1939379105 has a repro of a community user's inability to open slices if they came from a pcap with cooked-mode/SLL link layer protocol. The version of google/gopacket that Brimcap has been pointing to lacks support for this, but it looks like ongoing gopacket work has moved to another fork and that includes support for this. This PR points Brimcap at that fork.
As usual, I don't claim Go expertise so all I've done here is a 1-for-1 swap of gopacket/gopacket references in place of google/gopacket and ran go mod tidy. If that should have been done differently, guidance would be appreciated!
Assuming this passes CI, are there additional audits we should perform before depending on the fork? The licensing looks similar, FWIW.
I noticed the multiple comments where we say we copied and modified some code based on stuff from google/gopacket. Since we're not changing any of that code here I assume there's no action needed related to that. But I figured I'd point it out just in case.
tl;dr
https://github.com/brimdata/brimcap/issues/19#issuecomment-1939379105 has a repro of a community user's inability to open slices if they came from a pcap with cooked-mode/SLL link layer protocol. The version of google/gopacket that Brimcap has been pointing to lacks support for this, but it looks like ongoing gopacket work has moved to another fork and that includes support for this. This PR points Brimcap at that fork.
Fixes #19
Details
I learned of the fork after finding mention of cooked mode support in https://github.com/google/gopacket/pull/933 and that the enhancement actually got merged at a different fork via https://github.com/gopacket/gopacket/pull/1. Indeed, google/gopacket has not seen a commit since August, 2022 and has not tagged a release since October, 2020. Meanwhile, it looks like https://github.com/google/gopacket/issues/1016 is the best narrative that summarizes the semi-abandoned nature of https://github.com/google/gopacket and pointing everyone at https://github.com/gopacket/gopacket.
As usual, I don't claim Go expertise so all I've done here is a 1-for-1 swap of
gopacket/gopacketreferences in place ofgoogle/gopacketand rango mod tidy. If that should have been done differently, guidance would be appreciated!But FWIW, this alone seems to have the desired effect. Compared to what's shown in the closing remark of https://github.com/brimdata/brimcap/issues/19#issuecomment-1939379105, using a Brimcap based on this branch, now it shows the link type as supported.
And pointing my Zui at this Brimcap commit, the pcap slice can now be successfully extracted.
https://github.com/brimdata/brimcap/assets/5934157/3e2b0d12-8e9a-4661-a477-de330b598aef
Questions for reviewers
Assuming this passes CI, are there additional audits we should perform before depending on the fork? The licensing looks similar, FWIW.
I noticed the multiple comments where we say we copied and modified some code based on stuff from
google/gopacket. Since we're not changing any of that code here I assume there's no action needed related to that. But I figured I'd point it out just in case.