Example: > ipfw add 45000 count icmptypes 1,2 45000 count ip from any to any icmptypes 1,2 > ipfw add 45001 count not icmptypes 1,2 45001 count ip from any to any not icmptypes 1,2 > ipfw add 45002 count icmp6types 135,136 45002 count ip from any to any ip6 icmp6types 135,136 > ipfw add 45003 count not icmp6types 135,136 45003 count ip from any to any ip6 icmp6types 135,136 > ipfw show 45000-45003 45000 0 0 count ip from any to any icmptypes 1,2 45001 0 0 count ip from any to any not icmptypes 1,2 45002 0 0 count ip from any to any ip6 icmp6types 135,136 45003 0 0 count ip from any to any ip6 icmp6types 135,136 There's no difference between 45002 & 45003.
Created attachment 198919 [details] Proposed patch Can you try this patch?
A commit references this bug: Author: ae Date: Sat Nov 3 20:05:50 UTC 2018 New revision: 340100 URL: https://svnweb.freebsd.org/changeset/base/340100 Log: Do not use bzero() for the O_ICMP6TYPE opcode. The buffer is already zeroed in compile_rule() function, and also it may contain configured F_NOT flag in o.len field. This fixes the filling for "not icmp6types" opcode. PR: 232939 MFC after: 3 days Changes: head/sbin/ipfw/ipv6.c
After being patched /sbin/ipfw seems to be ok, in part of this issue. Thanks! And by the way, the word 'ip6' is confusing for example, one of my rules: ipfw list 32442 32442 count tag 64 ip from table(107,11) to table(107,11) not ip6 icmp6types 136 Then I copy this output to new command line: ipfw add 50000 count tag 64 ip from 'table(107,11)' to 'table(107,11)' not ip6 icmp6types 136 50000 count tag 64 not ip6 from table(107,11) to table(107,11) ip6 icmp6types 136 Rule 50000 is meaningless
A commit references this bug: Author: ae Date: Tue Nov 6 07:41:32 UTC 2018 New revision: 340175 URL: https://svnweb.freebsd.org/changeset/base/340175 Log: Do not print "ip6" keyword in print_icmp6types() for O_ICMP6TYPE opcode. It produces incompatibility when rules listing is used again to restore saved ruleset, because "ip6" keyword produces separate opcode. The kernel already has the check and only IPv6 packets will be checked for matching. PR: 232939 MFC after: 3 days Changes: head/sbin/ipfw/ipv6.c
> ipfw list 32442 32442 count tag 64 ip from table(107,11) to table(107,11) not icmp6types 136 Thank you, now it looks fine.
A commit references this bug: Author: ae Date: Fri Nov 9 08:14:48 UTC 2018 New revision: 340277 URL: https://svnweb.freebsd.org/changeset/base/340277 Log: MFC r340100: Do not use bzero() for the O_ICMP6TYPE opcode. The buffer is already zeroed in compile_rule() function, and also it may contain configured F_NOT flag in o.len field. This fixes the filling for "not icmp6types" opcode. MFC r340175: Do not print "ip6" keyword in print_icmp6types() for O_ICMP6TYPE opcode. It produces incompatibility when rules listing is used again to restore saved ruleset, because "ip6" keyword produces separate opcode. The kernel already has the check and only IPv6 packets will be checked for matching. PR: 232939 Approved by: re (kib) Changes: _U stable/12/ stable/12/sbin/ipfw/ipv6.c
A commit references this bug: Author: ae Date: Fri Nov 9 08:15:58 UTC 2018 New revision: 340278 URL: https://svnweb.freebsd.org/changeset/base/340278 Log: MFC r340100: Do not use bzero() for the O_ICMP6TYPE opcode. The buffer is already zeroed in compile_rule() function, and also it may contain configured F_NOT flag in o.len field. This fixes the filling for "not icmp6types" opcode. MFC r340175: Do not print "ip6" keyword in print_icmp6types() for O_ICMP6TYPE opcode. It produces incompatibility when rules listing is used again to restore saved ruleset, because "ip6" keyword produces separate opcode. The kernel already has the check and only IPv6 packets will be checked for matching. PR: 232939 Changes: _U stable/11/ stable/11/sbin/ipfw/ipv6.c
Fixed in head/, stable/12 and stable/11. Thanks!