Finally, with a lot of delay, I've just released the first full public version of my nftables code (including userspace), which is intended to become a successor to iptables. Its written from scratch and there are numerous differences to iptables in both features and design, so I'll start with a brief overview. There are three main components: - the kernel implementation - libnl netlink communication - nftables userspace frontend The kernel provides a netlink configuration interface, as well as runtime ruleset evaluation using a small classification language interpreter. libnl contains the low-level functions for communicating with the kernel, the nftables frontend is what the user interacts with. Kernel ------ The first major difference is that there's no one-to-one relation of matches and targets available to the user and those implemented in the kernel anymore. The kernel provides some generic parameterizable operations, like loading data from a packet, comparing data with other data etc. Userspace combines the individual operations appropriately to get the desired semantic. Data is represented in a generic way inside the kernel and the operations are defined on the generic data representations, meaning its possible to use any matching feature (ranges, masks, set lookups etc.) with any kind of data. Semantic validation of the operation is performed in userspace, the kernel doesn't care as long as the operation doesn't potentially harm the kernel. The kernel doesn't have a distinction between matches and targets anymore, operations can be arbitrarily chained, fixing a common complaint that multiple rules are required to f.i. log and drop a packet. Terminal operations will stop evaluation of a rule, even if further operations are specified. Userspace warns about rules containing operations after unconditionally terminal operations. Some operations can be runtime-parameterized, f.i. the "meta" module, which can change meta-data like packet marks. This can ...
Hm, how does one do traditional logging to syslog? Some of us just do logging for debugging purposes and would not otherwise need the full-blown nf_log solution - let alone there be enough space on some constrained Does it use the old limit code (which has numerous accuracy problems The libnl repositories (both original and yours) is missing tags. (Cc'ing Thomas). The unannotated tags can be got from git://dev.medozas.de/libnl . This makes it easier to get version numbers instead of How about storing the actual text the user inputed in something like an -m comment, as an aid to the user for finding his rules again after they have been optimized internally? --
It doesn't use either, but it won't have the old accuracy problems either once Thats not really necessary so far, and I don't want to in any case. If someone really wants this (and I very much question the need), it can be done in userspace. --
The rule snippets under tests/ pretty much all use obsolete syntax, so I'm attaching a test script (which doesn't make much sense, just testing features) so people can get a feeling for the syntax.
Interesting, that looks very much like ferm's syntax: http://ferm.foo-projects.org/ http://ferm.foo-projects.org/download/examples/webserver.ferm http://ferm.foo-projects.org/download/examples/dsl_router.ferm (ferm is a popular frontend for iptables, developed in 2000 by Auke Kok; I took over maintainership a few years ago) Good to see this is finally adopted by core netfilter tools! Max --
Indeed, it looks pretty similar :) The function things is also something I wanted to add later on. Currently I'm looking for a nice syntax to declare, define and modify sets outside of rules. I'll have a look at your manual, maybe I can find something I like :) --
I've thought about a "skin" in userspace to parse the iptables syntax and convert it to the new syntax. But the kernel won't have a compatibility interface and I'm not sure yet whether userspace will also be able to output iptables syntax. ipchains etc. definitely not. --
So, in that case if you are not going to provide a "skin" and that iptables will be removed eventually. wouldnt it break applications using iptables? --
Something will have to be done for compatibility, the skin is probably the easiest way. Compatibility on the kernel side would get incredibly ugly, I prefer something in userspace with a longer transition period. But all of this is still quite some time away :) --
|Greg KH||Og dreams of kernels|
|Jens Axboe||[PATCH 31/33] Fusion: sg chaining support|
|Arnd Bergmann||Re: finding your own dead "CONFIG_" variables|
|Mark Brown||[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset|
|Tony Breeds||[LGUEST] Look in object dir for .config|
|Brian Downing||Re: Git in a Nutshell guide|
|John Benes||Re: master has some toys<|