similar to: [Bug 616] Duplicate rules for multi-homed hostnames. IPv4 and IPv6 inconsistent treatment.

http://bugzilla.netfilter.org/show_bug.cgi?id=616 Summary: Duplicate rules for multi-homed hostnames. IPv4 and IPv6 inconsistent treatment. Product: iptables Version: unspecified Platform: i386 OS/Version: All Status: NEW Severity: minor Priority: P4 Component: iptables

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #5 from - <kd6lvw at yahoo.com> 2013-07-09 03:45:06 CEST --- Re: Comment #4. One doesn't know what the addresses are until they are retrieved from the DNS. The point is that the routines which generate the rules are NOT checking the values AFTER the CIDR netmask is applied to eliminate POST-MASK duplicate answers. The

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #9 from - <kd6lvw at yahoo.com> 2013-07-09 19:56:29 CEST --- RE: Comment #7: "It seems your best solution is to add a single rule with 208.83.136.0/22." Yet, it adds THREE rules, two of which will never fire, thus the problem and bug report. Extend your quota example: When the first rule reaches the quota, it will

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #11 from - <kd6lvw at yahoo.com> 2013-07-09 21:48:05 CEST --- I fully disagree that the addition of duplicate rules that will never be reached is part of the design. As a waste of memory allocation, it is inefficient and therefore incorrect. The use of a hostname in place of an IP address literal should not have any effect in

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #8 from Phil Oester <netfilter at linuxace.com> 2013-07-09 15:56:45 CEST --- (In reply to comment #7) > It is the duty of the software to properly execute that policy. Here, the > software fails to do so because it produces duplicate redundant rules which are > never used. And where is it documented that the software

https://bugzilla.netfilter.org/show_bug.cgi?id=616 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #10 from Phil Oester

https://bugzilla.netfilter.org/show_bug.cgi?id=616 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |netfilter at linuxace.com --- Comment #3 from Phil Oester <netfilter at linuxace.com> 2013-06-21

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #4 from Phil Oester <netfilter at linuxace.com> 2013-07-08 23:33:07 CEST --- As noted, #2 is solved already. Also, /128 will no longer print (commit 945353a2). But your #1 makes little sense to me: discovery.razor.cloudmark.com/22. How do you know that EVERY IP returned from a DNS lookup is always going to be a /22 mask?

https://bugzilla.netfilter.org/show_bug.cgi?id=616 --- Comment #6 from Phil Oester <netfilter at linuxace.com> 2013-07-09 03:50:27 CEST --- Yes, I fully understand what is happening in the one specific example you have provided. However you need to answer what happens if Cloudmark suddenly decides to add an IP _OUTSIDE_ of that /22 that is assigned to them. Let's say they open a new

http://bugzilla.netfilter.org/show_bug.cgi?id=630 Summary: Enhancement: Allow rules to specify ICMP type ranges. Product: iptables Version: unspecified Platform: All URL: http://www.ietf.org/rfc/rfc4890.txt OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: ip6tables

https://bugzilla.netfilter.org/show_bug.cgi?id=1413 Bug ID: 1413 Summary: Inconsistent EBUSY errors when adding a duplicate element to a map Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: normal Priority: P5

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=441 laforge@netfilter.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From laforge@netfilter.org

https://bugzilla.netfilter.org/show_bug.cgi?id=1349 Bug ID: 1349 Summary: "nft list ruleset" shows rules twice Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: minor Priority: P5 Component: nft Assignee: pablo at

https://bugzilla.netfilter.org/show_bug.cgi?id=1364 Bug ID: 1364 Summary: nft list outputs mark rules with boolean or in a form that can be parsed by nft -f Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P5

https://bugzilla.netfilter.org/show_bug.cgi?id=1082 Bug ID: 1082 Summary: Hard lockup when inserting nft rules (esp. ct rule) Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: blocker Priority: P5 Component: kernel Assignee:

https://bugzilla.netfilter.org/show_bug.cgi?id=1449 Bug ID: 1449 Summary: nft ipv4 set with interval issue Product: nftables Version: unspecified Hardware: x86_64 OS: other Status: NEW Severity: blocker Priority: P5 Component: nft Assignee: pablo at netfilter.org

http://bugzilla.netfilter.org/show_bug.cgi?id=580 Summary: iptables-restore and iptables-save lack comparison of a saved ruleset against the currently deployed rules Product: iptables Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1

https://bugzilla.netfilter.org/show_bug.cgi?id=1327 Bug ID: 1327 Summary: Cannot use named set for matching IPv4 networks Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: major Priority: P5 Component: nft Assignee: pablo at

https://bugzilla.netfilter.org/show_bug.cgi?id=1219 Bug ID: 1219 Summary: nftables prints the routing header type rules incorrectly Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft

https://bugzilla.netfilter.org/show_bug.cgi?id=1117 Bug ID: 1117 Summary: Table ipv4-nat prerouting dnat doesn't accept dest IP:PORT Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft