search

IETF-OPSAWG-WG / draft-ietf-opsawg-pcap

PCAP next generation file format specification
Other
264 stars 59 forks source link

Is it legal for an EPB capture length value to be different than snaplen/origlen? #35

Open hadrielk opened 9 years ago

hadrielk commented 9 years ago

Currently the draft says this for EPB's (and the deprecated Packet Block) Capture Length field:

Captured Packet Length: number of bytes captured from the packet (i.e. the length of the Packet Data
field). It will be the minimum value among the Original Packet Length and the snapshot length for the
interface (SnapLen, defined in Figure 10).

So does this mean it MUST be MIN(SnapLen, Original Packet Length), and cannot be more or less than it? (unless SnapLen is 0 obviously)

I ask because Wireshark currently just uses the Capture Length value, ignoring the SnapLen and Original Packet Length. I had thought this was just a bug in Wireshark, but I'm not sure it is. One could argue that the IDB's SnapLen should only apply to the capture length of Simple Packet Blocks.

packetfoo commented 9 years ago

No, Packet Capture Length can be less than SnapLen, so I think we have to change this. SnapLen is just one value for all packets, but we may see packets with different "captured packet length" values.

One example is that when cutting packets after the TCP header the actual remaining capture packet length depends on the length of the IP and TCP headers (which may vary for multiple packets, depending on what options were present). So Wireshark is doing it right in my point of view.

IDBs SnapLen seems only relevant for SPBs, as you mentioned.

guyharris commented 9 years ago

I.e., SnapLen is only "normative" for SPBs; it's just "informative" if you don't have any SPBs, as in "just thought you might like to know that this was the slicing length specified when the capture was done"?

packetfoo commented 9 years ago

Yes, SPBs need the SnapLen info. EPB may have a smaller packet capture length.

hadrielk commented 9 years ago

A file could contain both EPBs and SPBs, and according to the spec this may happen because: "for example, a capture tool could switch from Enhanced Packet Blocks to Simple Packet Blocks when the hardware resources become critical."

Of course I seriously doubt anyone would ever do that, but let's pretend it's true - so you'd put the SnapLen in the IDB "just in case" you start writing SPBs later in that file.

In hindsight, I think the SPB should probably never have been defined. We could have just reserved max value for the timestamp field to mean "unknown time". Saving 16 bytes in exchange for the extra complexity/confusion of having an SPB seems silly.

On Sat, Aug 29, 2015 at 2:35 PM, Guy Harris notifications@github.com wrote:

I.e., SnapLen is only "normative" for SPBs; it's just "informative" if you don't have any SPBs, as in "just thought you might like to know that this was the slicing length specified when the capture was done"?

— Reply to this email directly or view it on GitHub https://github.com/pcapng/pcapng/issues/35#issuecomment-136022171.

hadrielk commented 9 years ago

What if the EPB's Capture Length field is bigger than SnapLen?

On Sat, Aug 29, 2015 at 3:27 PM, Jasper Bongertz notifications@github.com wrote:

Yes, SPBs need the SnapLen info. EPB may have a smaller packet capture length.

— Reply to this email directly or view it on GitHub https://github.com/pcapng/pcapng/issues/35#issuecomment-136027902.

packetfoo commented 9 years ago

I was thinking about a bigger Capture Length than SnapLen and I think it's unlikely but not impossible. Some packets may be edited at a later time (e.g. sanitizing them, or preparing a replay) where the packet ends up with more bytes than were captured. In that case Capture Length could exceed SnapLen.

guyharris commented 5 years ago

One possibility might be to describe SnapLen as a limit specified as part of the capture process, and indicate that packets in an EPB (or PB) might have a capture length greater than the SnapLen if the packet content has been edited. However, we must then indicate that packets in an SPB MUST not be edited in any fashion that changes their length.