Use gopacket/gopacket instead of google/gopacket #336
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
tl;dr
#19 (comment) 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 google/gopacket#933 and that the enhancement actually got merged at a different fork via gopacket/gopacket#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 google/gopacket#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/gopacket
references in place ofgoogle/gopacket
and 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 #19 (comment), 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.
Fix.mp4
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.