On Sat, Sep 26, 2020 at 07:21:00PM +0000, ѽ҉ᶬḳ℠ wrote:
>
> On 26/09/2020 21:07, Pablo Neira Ayuso wrote:
> > On Sat, Sep 26, 2020 at 06:44:00PM +0000, ѽ҉ᶬḳ℠ wrote:
> > > On 26/09/2020 20:21, Pablo Neira Ayuso wrote:
> > > > On Fri, Sep 25, 2020 at 07:10:00PM +0000, ѽ҉ᶬḳ℠ wrote:
> > > > > Been trying to concatenate sets update:
> > > > >
> > > > > tcp dport @b_t update @b_sa4 { ip saddr } drop;
> > > > > tcp dport @b_t update @b_sa6 { ip6 saddr } drop;
> > > > >
> > > > > with:
> > > > >
> > > > > tcp dport @b_t update @b_sa4 . @b_sa4 { ip saddr . ip6 saddr } drop;
> > > > What's the intention here?
> > > >
> > > > > but that did not work out. Is somehow possible to concatenate sets update?
> > > > Yes, you can do:
> > > >
> > > > tcp dport @b_t update @b_sa4 { ip saddr . ip6 saddr } drop
> > > >
> > > > You can update one single set at a time. Not sure what you expect from
> > > > this concatenating sets instead of keys.
> > > The two mentioned sets are dynamic, learning ip | ip6 saddrs from hits on
> > > tcp dport.
> > >
> > > The intended concatenation was to put it into one rule instead of two, like
> > > if ip saddr then update element in set @b_sa4 and if ip6 saddr then update
> > > element in set @b_sa6 respectively.
> > So you would like to consolidate:
> >
> > tcp dport @b_t update @b_sa4 { ip saddr } drop
> > tcp dport @b_t update @b_sa6 { ip6 saddr } drop
> >
> > In one single rule?
> >
> > Something like (hypothetical syntax)
> >
> > tcp dport @b_t update @b_sa { inet saddr } drop
> >
> > where b_sa is a set with something like type inet_addr.
>
> In a way yes, though this would consolidate also ip and ip6 into the same
> set and could make viewing (a large) set it bit cumbersome, unless there was
> an optional view filter something like
>
> nft list set [family] [table] filter [set] ( optional [ip] | [ip6] )
General set infrastructure that provides an abstraction for IPv4 and
IPv6 through inet is possible, yes.
