pcapgo/read.go: Shouldn't ReadPacketData try to peek the packet header to check for corruption before reading?
- Dominant language
- Go
- Stars
- 6.8k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
In this code section:
https://github.com/google/gopacket/blob/a35e09f9f224786863ce609de910bc82fc4d4faf/pcapgo/read.go#L119-L140
I think maybe ReadPacketData should peek 16 bytes, check for corruption according to the [packet header specs](https://wiki.wireshark.org/Development/LibpcapFileFormat#Record_.28Packet.29_Header), and if there is corruption then skip 1 bytes.
My thinking is that maybe the next good packet header can start somewhere in the last 15 bytes of the 16 bytes read.
Right now, if there is corruption somewhere in the input file, pcapgo/read.go reads in increments of 16 bytes and might miss on good packets.
This of course will be much slower when dealing with a corrupted pcap file, but OTOH might find more good packets otherwise missed.
Contributor guide
Assessment
This issue has not been assessed yet.