Valerii Zapodovnikov

> most definitely _will_ be 0xFFFF What it should be here?? Because if you will hex edit the file and edit 0xFFFF there or 0x0000, it will print in both...

So as I understand it, we should add a check if there exist non-zero bits IN ICMP itself (no psuedo header, not like in ICMPv6) && checksum calculated is 0xFFFF,...

TCP packet with 0xFFFF was also seen in the wild! Though it is TCP in IPV4 **in GPRS** https://gitlab.com/wireshark/wireshark/-/issues/16816 That caused a https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25862 in Wireshark. Nice.

> there is no problem, is this the conclusion of this case? What? No, there is only NO problem in ICMV6, because even if all bits are zero due to...

> In the specific case of IPv4 ICMP the checksum can be 0x0000, which appears in the wire encoding as 0xFFFF. That's what everyone agrees about, correct? Not correct at...

I will just remind you that wireshark uses scripts to update all of it (SMI as well) once in 7 days. Like that https://code.wireshark.org/review/c/37293/

Part two... https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-forces.c#L108 node >= 0x40000000 is always true... The use of macro ND_TTEST_LEN() is really bad. I mean here are warnings for just one file. print-fr.c 105 always true...

@fxlb So what? Do I need to create pull request or what?

> However, it seems that converting between sRGB and YCbCr requires a specific YCbCr color space. No, it does not. Yes, ideally one should use YCbCr matrix that is BT.709...

Such problems are almost always connected to uint64_t.