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

[hadrielk]

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]

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]

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]

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

[hadrielk]

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
#35 (comment).

[hadrielk]

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
#35 (comment).

[packetfoo]

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]

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.