Closed JulianSchmid closed 5 months ago
FYI: I just pulled master as part of my pull request and tried to run it and it broke most of my project :-( A super common case for "lax" parsing is an ICMP TTL Unreachable message which has a fraction of the expired packet as the ICMP message's payload. The 'fraction' is defined as the full IP header and "at least 8 bytes" of the transport header, which depending on the router may be exactly 8 bytes or maybe the full packet plus an ICMP Extension.
Is the plan for this "from_slice_lax" to end up in 0.14 before it ships? Can I help? Thanks in advance.
@robs-zeynet The plan is to ship the next version with a lax parser, otherwise I kind of pull support for something I supported previously.
That is actually the main reason why I have not yet released a new version, even though quiet a lot of changes have pilled up on the master branch. But I wanted to be done waaay earlier, but life happened and I did not find enough time the last few months.
As the validation of length values will become stricter with https://github.com/JulianSchmid/etherparse/issues/35 there should still be a way to still parse packets in a a "laxer" way. As part of this ticket
from_slice_lax
methods should be added that are not as strict about the correctness of the packet contents, but instead try to parse the packets as far as possible and substitute missing informations whenever possible.This can be use-full in setups where only the needed parts in a network packet are set. The total_length field can be for example be set to zero if the total packet length is known and no padding is present. It is then still possible to determine the length of the payload (or total_length) by using the length of the slice as a substitute value.