Bug 200897 - ipset hash:net,port,net rejects CIDR 0 despite man page
Summary: ipset hash:net,port,net rejects CIDR 0 despite man page
Status: RESOLVED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: Netfilter/Iptables (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_netfilter-iptables@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-22 16:47 UTC by Eric Westbrook
Modified: 2018-09-01 18:27 UTC (History)
0 users

See Also:
Kernel Version: 4.18.3
Tree: Mainline
Regression: No


Attachments
Allow /0 as advertised (1.53 KB, patch)
2018-08-28 21:18 UTC, Eric Westbrook
Details | Diff

Description Eric Westbrook 2018-08-22 16:47:34 UTC
The `ipset` man page says:

    hash:net,port,net
        The hash:net,port,net set type  behaves  similarly
        to  hash:ip,port,net  but accepts a cidr value for
        both the first and last parameter.  Either  subnet
        is  permitted  to be a /0 should you wish to match
        port between all destinations.

But the following input generates `IPSET_ERR_INVALID_CIDR` anyway.

    # ipset restore
    create cidrzero hash:net,port,net family inet hashsize 1024 maxelem 65536 counters comment
    add cidrzero 0.0.0.0/0,12345,0.0.0.0/0
    ipset v6.34: Error in line 2: The value of the CIDR parameter of the IP address is invalid

Using non-zero addresses doesn't help, nor does only assigning one or the other CIDR to 0 rather than both.

Am I doing it wrong?  How is it supposed to be done?

 - Kernel 4.18.3
 - ipset userland 6.34
Comment 1 Eric Westbrook 2018-08-28 21:18:56 UTC
Created attachment 278185 [details]
Allow /0 as advertised

Fix hash:net,port,net for advertised /0 behavior.  Submitted by email to LKML, netfilter-devel, and netfilter maintainers.

See also https://github.com/ewestbrook/linux/commit/df7ff6efb0934ab6acc11f003ff1a7580d6c1d9c

Note You need to log in before you can comment on or make changes to this bug.