-
Notifications
You must be signed in to change notification settings - Fork 0
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
[feature] Remove debugging statements in ring buffer source #54
[feature] Remove debugging statements in ring buffer source #54
Conversation
@@ -398,8 +398,6 @@ func (s *Source) determineTotalPktLen(payload []byte) (uint16, error) { | |||
return toUint16(payload[s.ipLayerOffset+4 : s.ipLayerOffset+6]), nil | |||
} | |||
|
|||
// TODO: What about jumbo packets? At least for IPv6 such packets carry additional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I checked, regular Jumbo packets are handled correctly. Only IPv6 Jumbograms would fail as they carry extended information in the header (which would also affect the ring buffer source I assume). Unfortunately I wasn't able to simulate such packets (nor was I able to find a pcap source or similar). It seems its use is so uncommon that almost nobody has succeeded in crafting valid data that uses this feature, so I assume it's a non-issue in real life.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx
golang.org/x/net v0.8.0 | ||
golang.org/x/sys v0.6.0 | ||
github.com/stretchr/testify v1.8.4 | ||
go.uber.org/zap v1.25.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could (aka should) be log/slog
:)
Preparation for initial release of slimcap. Will merge once all alpha tests check out.
Closes #6