Hi, On Mon, May 15, 2017 at 02:03:57PM +0200, Florian Westphal wrote: > bugzilla-daemon@xxxxxxxxxxxxx <bugzilla-daemon@xxxxxxxxxxxxx> wrote: > > [ Switching to email ] > > > https://bugzilla.netfilter.org/show_bug.cgi?id=1145 > > > > --- Comment #1 from Ian Kumlien <ian.kumlien@xxxxxxxxx> --- > > Is there anything obvious that i'm doing wrong? Is there something else i could > > try? > > This boils down to nested sets: > > define dnat_host = 10.1.2.3 > define dnat_ports = { 1234-1567 } > > define port_allow = { > 53, # dns > $dnat_ports, # dnat > } > define port_allow_tcp = { > 80, > 443, > $port_allow > } > define port_allow_udp = { > 67, 68, # dhcp > 123, 1027, # ntp > $port_allow > } > > ... which we don't support at the moment. Actually, we do support this kind of nesting: Back in March I sent a number of patches to fix for nested sets constructed via defines like above, see a6b75b837f5e8 ("evaluate: set: Allow for set elems to be sets") and the following two for details. The reason why above fails though is the use of a range in dnat_ports. If I drop it from the port_allow define, the above is accepted and appears correct. > So, should we > a). expand/'inline' the sets? > > (i.e. port_allow_tcp would contain > 1234-1567, 53, 80, 443) This is what I would expect the above to turn into. > b) support lookups within lookups? > > This would be needed to support non-anonymous sets within sets. Sounds like a nice project, but for the issue at hand I don't think it's necessary. So maybe get this issue (range in set not allowed) fixed and postpone the named set in set thing for later? :) Cheers, Phil -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
