On Thu, Aug 03, 2023 at 09:38:47PM +0200, Jan Engelhardt wrote: > > On Thursday 2023-08-03 14:57, 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). > >> > >> v1.2.7a-35-gfc9237da missed touching *libip6t_icmp6.c*, so > >> it was never updated with the same "bug".[...] > > > >One could extend icmp6 match (in kernel and user space) to support this > >"any" type, though it seems not guaranteed the value 255 won't be used > >for a real message at some point. So a proper solution was to support type > >ranges like ebtables does. Then "any" type is 0:255/0:255. > > > >Apart from the above, the three patches of this series should be fine, > >right? > > Yeah. I have applied the series apart from patch 2: The wrong XTOPT_MAND flag is present since v1.4.11, if anyone actually depends on the behaviour, they would have complained. So leaving things as they are is fine, and instead one should go into another direction: - Drop XTOPT_MAND and instead provide a better error message in x6_fcheck callback, pointing out that '-p icmp -m icmp' is equivalent to plain '-p icmp'. - Same for '--icmp-type any'? In theory, it's pointless. A nicer option would be to turn '-m icmp [--icmp-type any]' into a NOP. Using '-p icmp' is mandatory anyway. There's no support for matches to remove themselves, though. I guess this could be done by extending xtables_option_mfcall(). Cheers, Phil
