lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 21 Nov 2007 01:25:54 +0100
From:	Patrick McHardy <>
To:	David Miller <>
Subject: Re: [PATCHv6 0/3] Interface group patches

David Miller wrote:
> From: Laszlo Attila Toth <>
> Date: Tue, 20 Nov 2007 14:52:12 +0100
>> Jan Engelhardt írta:
>>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote:
>>>> This is the 6th version of our interface group patches.
>>>> The interface group value can be used to manage different interfaces
>>>> at the same time such as in netfilter/iptables.
>>> I take it you could not use...?
>>> 	iptables -i iif1 -j dosomething
>>> 	iptables -i iif2 -j dosomething
>> This kind of usage requires static interface names. But there are 
>> dynamic interfaces such as ppp, where the actual name is not always 
>> known or sometimes they exist sometimes not. It is difficult to use 
>> iptables this way, and every ifup/ifdown requires change in the iptables 
>> ruleset (donwload it, modify and upload to the kernel). It may be too slow.
> This is actually not true these days.
> When network devices are created user events are generated and the
> user can rename the device however they like using a mapping table of
> any kind.
> And at such point the problem you present doesn't actually exist, you
> can know what the device will be named.
> And if rule loading dynamically is slow, we should fix that instead of
> creating infrastructure and interfaces we don't actually need.

I actually like this feature. Matching on names in iptables
has always been one of the major bottlenecks, taking
(according to my last measurement, which is some time ago)
about 1-2% of the total performance. This is of course in
large parts because the interface match is present on *every*
rule, but still some way to logically group interfaces seems
useful to me, not only for iptables, but also for routing rules,
traffic classifiers, af_packet sockets etc.

I'm working on the incremental ruleset changing API BTW :)
One of the changes will be that interface matching is not
a default part of every rule, and without wildcards it will
use the ifindex. But since the cost of this feature seems
pretty low, I don't see a compelling reason against it.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists