New version length checks & packets captured with a smaller snaplen

[GyulyVGC]

Hi @JulianSchmid, first of all thank you for the huge work behind v0.14.

I noticed that now when packets have a smaller length than expected, an error is returned.
This can be a problem in cases where packets are captured in a context for which a small snaplen has been specified.

The solution I figured out is to use instead LaxPacketHeaders; using the lax strategy, everything seems to behave as expected.

Can you confirm that this strategy produces consistent results with PacketHeaders in v0.13?

In particular, there is one item of the LaxPacketHeaders that is confusing me:

Length in the IP header & UDP headers are allowed to be inconsistent with the given slice length (e.g. data is missing from the slice). In this case it falls back to the length of slice. See LaxIpSlice::from_slice for a detailed description of when the slice length is used as a fallback.

From the description it seems that in case the length is inconsistent, the length of the snapped packet would be used.
However, I observe an average packets length of 1000, while my snaplen is set to 256.

So the result is what I expect, it's just that description that's leaving me with a doubt.

[JulianSchmid]

Hi @GyulyVGC ,

First thanks for the thank you 😄.

LaxPacketHeaders does not exactly behave the same way as PacketHeaders::from_X did in v0.13 . But I don't think it should have an influence on what you are seeing.

LaxPacketHeaders::from_x will restrict the payload to the payload length if the given slice is bigger then what is specified in the Ipv4Header::total_len, Ipv6Header::payload_len or UdpHeader::len. In case less data than expected is available it will just use the slice length (same as in v0.13). It will also fall back to the slice length in case a length in a header is inconsistent (e.g. if Ipv4Header::total_len is 0). v0.13 always used the slice length for the payload length, without reducing it if any header indicated less data.

But that does not explain what you describe here:

From the description it seems that in case the length is inconsistent, the length of the snapped packet would be used.
However, I observe an average packets length of 1000, while my snaplen is set to 256.

It should be equal or less. More data should appear, or at least etherparse (hopefully) should not be the root case of that. And if so, that would be a bug I would need to fix. Maybe the snaplen has an lower limit?

How do you get the packet length? Is there some specific part you use (e.g. the returned "rest" slice)? Then I could have a quick look if there is an issue.

Greets
Julian

[GyulyVGC]

Thank you very much for the very quick and detailed reply.

Maybe I'm just misinterpreting some concepts: probably I'm confusing the length you are referring to.

I simply take the length from Ip4Header::tot_len and Ipv6Hedaer::payload_length, and assuming that etherparse doesn't change the fields of the original packet headers, these should still report the length of the original packet, no matter if it has been applied a lower snaplen on it.

If this is the case, well everything works as expected.

[JulianSchmid]

Ah now I understand the question better. Etherparse will not modify any fields of the original headers, it only modifies the length of the slice stored in "LaxPacketHeaders::payload". The headers will be decoded with the original values (even if they are inconsistent).

So yes, reading theIpv6Hedaer::payload_len & Ip4Header::total_len will still give you the length of the original packet, even if the overall packet has been cut off.

[GyulyVGC]

Awesome! Sorry for the pretty stupid miscomprehension.

And again, you did a great job with the latest release!