RE: [PATCH] multiple devices with ranges match support

RE: [PATCH] multiple devices with ranges match support

[Eble, Dan]

> -----Original Message-----
> From: Jay Schulist [mailto:jschlst@linux-sna.org] 
> mdev v1.2.7a options:
...
>  --i dev[,dev:dev,dev...]       match inbound device(s)
>  --o dev[,dev:dev,dev...]       match outbound device(s)

Would you ever want to use this on interfaces with secondary addresses, like
eth0:4?  (Does that even matter?  I'm not too familiar with them; I just
remember seeing that syntax.)

Re: [PATCH] multiple devices with ranges match support

[Patrick Schaaf]

On Wed, Sep 18, 2002 at 02:52:31PM -0400, Eble, Dan wrote:
> > -----Original Message-----
> > From: Jay Schulist [mailto:jschlst@linux-sna.org] 
> > mdev v1.2.7a options:
> ...
> >  --i dev[,dev:dev,dev...]       match inbound device(s)
> >  --o dev[,dev:dev,dev...]       match outbound device(s)
> 
> Would you ever want to use this on interfaces with secondary addresses, like
> eth0:4?  (Does that even matter?  I'm not too familiar with them; I just
> remember seeing that syntax.)

Their use is deprecated (use "ip addr add ..." instead), but it's
nevertheless a good idea to avoid actively breaking them. However,
if I remember correctly, they don't really appear as input or
output device of real packets in the kernel, so in this place,
it's probably OK to reuse ':'.

However, in general, I'm not so sure that it makes sense to expand
all kinds of match options into multidimensional specification
languages for arbitrary subsets of their keyspaces, with all kinds
of option specific shortcut forms for how ranges and patterns are
written. Each option becomes its own mini-language. I don't like.

What's wrong with the good old subchain, and several "-i dev" lines
branching off to there?

<evil-idea-mode>
Or, to turn the approach around 180 degree, what about a "chain" match,
to be used like this:
iptables -N mydevs
iptables -A mydevs -i eth+ -j ACCEPT
iptables -A mydevs -i tap+ -j ACCEPT
iptables -A mydevs -j DROP
...
iptables -A somewhere -m chain --chain mydevs -p tcp --dport 22
<evil-idea-mode/>

best regards
  Patrick

P.S.: My deepest apologies, Jay, for you receiving so many rants from
me this evening. Please, don't take them personally. I hope to help.

Re: [PATCH] multiple devices with ranges match support

[Jay Schulist]

On Thu, 19 Sep 2002, Patrick Schaaf wrote:

> However, in general, I'm not so sure that it makes sense to expand
> all kinds of match options into multidimensional specification
> languages for arbitrary subsets of their keyspaces, with all kinds
> of option specific shortcut forms for how ranges and patterns are
> written. Each option becomes its own mini-language. I don't like.
>
> What's wrong with the good old subchain, and several "-i dev" lines
> branching off to there?
>

The reason I did the mdev ranges was to support 100s of virtual
interfaces/devices. In this case having a rule for each interface will
slow things down greatly compared to the efficient mdev match operation.

> P.S.: My deepest apologies, Jay, for you receiving so many rants from
> me this evening. Please, don't take them personally. I hope to help.
>

no problem, the feed-back/comments is great.

jay-s.

Re: [PATCH] multiple devices with ranges match support

[Harald Welte]

[-- Attachment #1: msg.pgp --]
[-- Type: application/pgp, Size: 2001 bytes --]

matching "many of one kind"

[Patrick Schaaf]

Harald & all,

> > However, in general, I'm not so sure that it makes sense to expand
> > all kinds of match options into multidimensional specification
> > languages for arbitrary subsets of their keyspaces, with all kinds
> > of option specific shortcut forms for how ranges and patterns are
> > written. Each option becomes its own mini-language. I don't like.
> 
> You seem to be reading my mind.  I already had this issue with the
> multiport match (I never liked it, in fact) - and I have the same 
> trouble with this kind of patches.  Somebody seems to be solving a 
> particular problem (efficiency?) the wrong way.

Do you have an idea about how to solve these efficiency problems?
I think we do have genuine cases on our hands that profit immensely
from such compact specification of more or less large one-dimensional
alternative lists. My ippool extension was born out of one such case,
where a small bitmap can replace hundreds of source or destination
IP specifications. Jay's multi-device-list, with his application
needing to match "one of 100 devices" out of a larger set, is
another good case.

With ippool, I decided to hide the "detailed list of set members"
in the ippool management, i.e. kept it away from normal rule
specification, so the rule management itself does not need a
more complicated API. This "trick" may as well be used for the
device list stuff, or for more complex multiport things (those
would be two new flavors of pools).

Do you know other approaches, maybe more logical / compact /
understandable, that may help us with this general problem?

Or, do you see iptables geared so much towards mainstream usage
that you don't worry too much about those pathologically complex
cases - after all, we proved that we can write our own specialcase
extensions to cover them, anyway. Note that this paragraph is not
meant as a sarcastic snide; such an approach could be taken.

In any case, before the iptables matches and targets become even
more baroque, I'd like to know what the core team things about
these issues.

best regards
  Patrick

Re: matching "many of one kind"

[Jozsef Kadlecsik]

Hi Patrick,

On Sat, 21 Sep 2002, Patrick Schaaf wrote:

> > > However, in general, I'm not so sure that it makes sense to expand
> > > all kinds of match options into multidimensional specification
> > > languages for arbitrary subsets of their keyspaces, with all kinds
> > > of option specific shortcut forms for how ranges and patterns are
> > > written. Each option becomes its own mini-language. I don't like.
> >
> > You seem to be reading my mind.  I already had this issue with the
> > multiport match (I never liked it, in fact) - and I have the same
> > trouble with this kind of patches.  Somebody seems to be solving a
> > particular problem (efficiency?) the wrong way.
>
> Do you have an idea about how to solve these efficiency problems?
> I think we do have genuine cases on our hands that profit immensely
> from such compact specification of more or less large one-dimensional
> alternative lists. My ippool extension was born out of one such case,
> where a small bitmap can replace hundreds of source or destination
> IP specifications. Jay's multi-device-list, with his application
> needing to match "one of 100 devices" out of a larger set, is
> another good case.
>
> With ippool, I decided to hide the "detailed list of set members"
> in the ippool management, i.e. kept it away from normal rule
> specification, so the rule management itself does not need a
> more complicated API. This "trick" may as well be used for the
> device list stuff, or for more complex multiport things (those
> would be two new flavors of pools).

In my opinion, we should accept and generalize ippool as the standard way
to express multiple possibilities of the same kind for iptables. The
matches could be extended as plain and ippool-aware ones, so that one
could write rules like

-i interface-pool -s address-pool -sport port-pool etc.

It'd involve extending ippool (nfpool) according to Joakim Axelsson's
suggestion by hash, list, btree and subpool pools as well.

> In any case, before the iptables matches and targets become even
> more baroque, I'd like to know what the core team things about
> these issues.

I completely agree with your message: the goal is to keep the interface
both clean and flexible. The proper way for multi-foo matching is to use
generalized pools, not introducing individual matches for every new
multi-foo.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] multiple devices with ranges match support

[Roberto Nibali]

Hi,

> Would you ever want to use this on interfaces with secondary addresses, like
> eth0:4?  (Does that even matter?  I'm not too familiar with them; I just
> remember seeing that syntax.)

eth0:4 is _not_ an interface, but a label. The underlying physical interface is 
eth0. Filtering should be per src addr selector and not by names.

Regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

[PATCH] multiple devices with ranges match support

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 390 bytes --]

Hello Harald,
Here is a new match which allows the user to match by using multiple comma
seperated devices each with range support.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

mdev v1.2.7a options:
 --i dev[,dev:dev,dev...]       match inbound device(s)
 --o dev[,dev:dev,dev...]       match outbound device(s)

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 2158 bytes --]

[-- Attachment #3: Type: APPLICATION/OCTET-STREAM, Size: 2565 bytes --]

[PATCH] multiple devices with ranges match support

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 390 bytes --]

Hello Harald,
Here is a new match which allows the user to match by using multiple comma
seperated devices each with range support.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

mdev v1.2.7a options:
 --i dev[,dev:dev,dev...]       match inbound device(s)
 --o dev[,dev:dev,dev...]       match outbound device(s)

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 2158 bytes --]

[-- Attachment #3: Type: APPLICATION/OCTET-STREAM, Size: 2565 bytes --]

Re: [PATCH] multiple devices with ranges match support

[Patrick Schaaf]

On Tue, Sep 17, 2002 at 11:47:42PM -0700, Jay Schulist wrote:
> Hello Harald,
> Here is a new match which allows the user to match by using multiple comma
> seperated devices each with range support.
> 
> Iptables userspace patch is against a clean iptables-1.2.7a
> Kernel patch is against a clean linux-2.4.19
> 
> mdev v1.2.7a options:
>  --i dev[,dev:dev,dev...]       match inbound device(s)
>  --o dev[,dev:dev,dev...]       match outbound device(s)

Wishlist item:

In the future, I wish the indev/outdev were gone from the generic
iptables rule, replaced with exactly such a match as Jay is presenting.
Maybe it could be more "built in", and the old plain "-i" and "-o"
would work without saying "-m mdev", but nevertheless do exactly that
internally. That way we'd have full backward compatibility, and all
those rulesets out there without device matches, would certainly
operate two cache lines (P-III, i.e. 64 byte total) per rule faster.

best regards
  Patrick

Re: [PATCH] multiple devices with ranges match support

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Thu, Sep 19, 2002 at 12:02:57AM +0200, Patrick Schaaf wrote:
> On Tue, Sep 17, 2002 at 11:47:42PM -0700, Jay Schulist wrote:
> > Hello Harald,
> > Here is a new match which allows the user to match by using multiple comma
> > seperated devices each with range support.
> > 
> > Iptables userspace patch is against a clean iptables-1.2.7a
> > Kernel patch is against a clean linux-2.4.19
> > 
> > mdev v1.2.7a options:
> >  --i dev[,dev:dev,dev...]       match inbound device(s)
> >  --o dev[,dev:dev,dev...]       match outbound device(s)
> 
> Wishlist item:
> 
> In the future, I wish the indev/outdev were gone from the generic
> iptables rule, replaced with exactly such a match as Jay is presenting.

yes. This is what I have in mind with pkt_tables.  I am going to post a
first, preliminary patch today.

> best regards
>   Patrick

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ 
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[PATCH] multiple devices with ranges match support

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 390 bytes --]

Hello Harald,
Here is a new match which allows the user to match by using multiple comma
seperated devices each with range support.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

mdev v1.2.7a options:
 --i dev[,dev:dev,dev...]       match inbound device(s)
 --o dev[,dev:dev,dev...]       match outbound device(s)

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2158 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 2565 bytes --]

[PATCH] multiple devices with ranges match support

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 390 bytes --]

Hello Harald,
Here is a new match which allows the user to match by using multiple comma
seperated devices each with range support.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

mdev v1.2.7a options:
 --i dev[,dev:dev,dev...]       match inbound device(s)
 --o dev[,dev:dev,dev...]       match outbound device(s)

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2158 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 2565 bytes --]