On Wednesday 2023-08-02 04:05, Phil Sutter wrote:
>
>It is not entirely clear what the fixed commit was trying to establish,
>but the save output is certainly not correct (especially since print
>callback gets things right).
>
>Fixes: fc9237da4e845 ("Fix '-p icmp -m icmp' issue (Closes: #37)")
"""(libipt_icmp.c):
* Up to kernel <=2.4.20 the problem was:
* '-p icmp ' matches all icmp packets
* '-p icmp -m icmp' matches _only_ ICMP type 0 :(
* This is now fixed by initializing the field * to icmp type 0xFF
"""
But also:
v1.2.7a-35-gfc9237da missed touching *libip6t_icmp6.c*, so
it was never updated with the same "bug".
In icmp6, --icmpv6-type was (and still is to this date) mandatory, which means
`-p icmp6 -m icmp6` would *not* implicitly go match ICMP(v6) type 0 like its
IPv4 counterpart.
Then, in v1.4.10-115-g1b8db4f4, libipt_icmp.c more or less accidentally gained
XTOPT_MAND (possible spill from IPv6 code), therefore `-p icmp -m icmp` would
also stop implicitly doing ICMP type "any".
