Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Sep 2005, Amin Azez wrote:

Does it also remove the "upload rules in bulk" issue of iptables and
make use of links lists (or trees) to upload small changes singly?

Yes. nf-HiPAC uses netlink messages for rule updates, carrying just the updates. It does not exchange complete rulesets on each update like iptables does.

I recall someone released a re-write a while ago that took care of this, but this seems to do rule-factoring too to reduce the number of check operations.

iptables per definition must always send a whole new iptable (compiled ruleset) to the kernel as one big blob as it is the userspace who constructs the iptable and the kernel has no knowledge (or capability) to modify an iptable inplace, only replace it with another submitted by userspace.

As nf-HiPAC is using another internal representation of the rules it does not need this, and the updates carry only the rules you are updating.

Speaking under fear of blasphemy I'm wondering what stops this becoming
iptables proper?

Not much. It is already very near a full replacement of iptables filter table. It does not yet have support for the other table types but it's trivial to add. The nat table has to wait for the completetion of the restructuring of the nat code currently taking place however, but after 2.6.14 this should not be a problem to implement from what I have understood. The problem currently is that the nat core nat is very tightly coupled with iptable_nat, but this is being addressed already by the Netfilter team.

OK, it would want linking to nf_conntrack instead of ip_conntrack

This should be trivial. The optional conntrack dependency is already well isolated in a separate very small module. Some of this isolated code obviously needs to be changed when using nf_conntrack but not much.

and a v6 version doing type stuff, but it seems the biz.

IPv6 requires a bit more work due to the larger key size in source/destination addresses. HiPAC currently only implements up to 32-bit lookup dimensions (source/destination/protocol/ports etc..).

Regards
Henrik



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux