On Wed, Mar 20, 2019 at 11:16 PM Karuna Grewal <karunagrewal98@xxxxxxxxx> wrote: > > On Tue, Mar 5, 2019 at 3:42 PM Florian Westphal <fw@xxxxxxxxx> wrote: > > > > Karuna Grewal <karunagrewal98@xxxxxxxxx> wrote: > > > I've a doubt in the nftables implementation for implementing the `-m > > > time` support. > > > > Full -m time is complicated, do not worry about this yet. > > > > > I'm unable to get a proper idea of where the start and > > > stop time comparison with the dest register's value takes place. > > > > Via the nftables evaluation loop. You only need to worry about placing > > the value (timestamp) in the dst register (on kernel side), so your > > patch looks pretty complete aside from the missing 'break'. > > > > Its userspace (nftables) responsibility to tell kernel to do something > > with the register, such as a compare or range. > > > > Have a look at > > http://git.netfilter.org/nftables/commit/src/meta.c?id=512795a673f999fb04b84dbbbe41174e9c581430 > > > > It should be enough to follow this approach, adding e.g. > > META_TEMPLATE("timestamp", .. > > > > we have TYPE_TIME already, even though its a relative one, it > > would/should work for a quick prototype. > > I had sent the patch for this basic case of simply comparing one timestamp. > As the startdate and stopdate options need to implemented completely, > should I make use of an interval > or is using two different tokens viz. START_TSTAMP and STOP_TSTAMP the > preferred option. Sorry, I had mistaken the way intervals were scanned in the rule. This above doubt is cleared. Moving on to the part of not using relative times would it be required to first implement it in the nftables datatypes or is there another available workaround using the existing nftables code?
