Re: [NEW EXTENSION] Condition Match

Re: [NEW EXTENSION] Condition Match

[Stephane Ouellette]

--- Harald Welte <laforge@gnumonks.org> wrote:

>> On Tue, Oct 29, 2002 at 10:43:07PM -0600, allen wrote:
>  
>
>>> > 
>>> > 
>>> > On Tuesday 29 October 2002 12:54 pm, Stephane Ouellette wrote:
>>    
>>
>>>> > >    I developped last week a new extension to Netfilter in order to
>>>> > > enable or disable a set of rules using /proc files.
>>>      
>>>
>>> > 
>>> > 
>>> > Yeah, as others have said, the idea is definitely cool.
>>    
>>
>> 
>> Though the idea is cool, I think we are solving a problem the wrong way.  Why
>> add complexity to the kernel for a problem which can be solved without
>> any problem from userspace?
>> 
>> Where is the problem in having a couple of different rulesets (e.g. created
>> with iptables-save) which are then loaded using an iptables-restore
>> commandline or a script at the shell of the firewall?
>

Harald,

   I have already tried the solution you propose on a production 
environment and it proved difficult to deal with.  Using the condition 
match, it is far faster to enable/disable rule sets than it is with a 
set of scripts.  It is also less error-prone on a management point of 
view as the firewall rules never change.

I would suggest that the condition match makes it to P-O-M, and let the 
users try it.

Regards,

Stephane Ouellette.

Re: [NEW EXTENSION] Condition Match

[allen]

On Thursday 31 October 2002 07:51 pm, Stephane Ouellette wrote:
> --- Harald Welte <laforge@gnumonks.org> wrote:
( snip )
> >> Where is the problem in having a couple of different rulesets (e.g.
> >> created with iptables-save) which are then loaded using an
> >> iptables-restore commandline or a script at the shell of the firewall?
>
> Harald,
>
>    I have already tried the solution you propose on a production
> environment and it proved difficult to deal with.  Using the condition
> match, it is far faster to enable/disable rule sets than it is with a
> set of scripts.  It is also less error-prone on a management point of
> view as the firewall rules never change.
>
> I would suggest that the condition match makes it to P-O-M, and let the
> users try it.

Yeah.

After thinking more about it, yeah.  It IS cool.

Note:

1.  Already many things are adjusted via /proc mechanism
    that are similar in that they are related to networking
    parameters that need to be modified on the fly.

2.  Making a modification to netfilter rules by dumping
    and loading new rules is not cool and is prone 
    to error "during the switch".

    This method is only straightforward, but actually
    more complex in operation.  ( The administrator
    has to think more )

3.  The other thing would be a libipq thing, and there
     can be only one.  And it is in userspace and
     it can die.

I think the /proc concept in this case is better than
the load/modify/delete/add kind of concept.

I'm having a hard time thinking of a better "thing" 
than /proc.

It seems like the next best alternative is yet again
some "new thing" that doesn't exist yet.

What new thing would be better than /proc ?

Who would "buy" something new ?  so to speak...

For what it is worth, I second the motion here.

-AEF

[NEW EXTENSION] Condition Match

[Stephane Ouellette]

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

Folks,

   I developped last week a new extension to Netfilter in order to 
enable or disable a set of rules using /proc files.

   As an example, I like to play Quake III Aerna with a few friends of 
mine but I don't want to keep the firewall rules that make them able to 
connect to my computer active at all times.  Adding and removing these 
specific rules is annoying...

    So my solution is illustrated by the following rules:

iptables -t nat -A PREROUTING -p udp -m condition -i $INTERNET --dport 
27960 --condition quake -j DNAT --to-destination $MYCOMPUTER
iptables -t filter -A FORWARD -p udp -m condition -i $INTERNET -o $LAN 
--dport 27960 --condition quake -j ACCEPT
iptables -t filter -A FORWARD -p udp -m condition -i $LAN -o $INTERNET 
--dport 27960 --condition quake -j ACCEPT


To enable the rules, issue:        echo 1 > /proc/net/ipt_condition/quake
To disable the rules, issue:       echo 0> /proc/net/ipt_condition/quake


The /proc files are created automagically when a new condition is 
defined and destroyed when no rule points to them anymore.

As of this writing, the condition match module supports only one 
condition per rule.  I think I will add in a near future the possibility 
to match on many conditions at the same time, using the syntax:     
--condition file1,file2,file3. . .

- It was tested under kernel 2.4.20-pre10-ac2
- So far so good, the condition match module seems stable !

Any comments, bug reports or suggestions would be greatly appreciated.

Enjoy !

Stephane.


[-- Attachment #2: condition.patch --]
[-- Type: text/plain, Size: 6835 bytes --]

diff -aruN linux-2.4.20-pre10-ac1-machiavel/include/linux/netfilter_ipv4/ipt_condition.h linux-2.4.20-pre10-ac1-machiavel-new/include/linux/netfilter_ipv4/ipt_condition.h
--- linux-2.4.20-pre10-ac1-machiavel/include/linux/netfilter_ipv4/ipt_condition.h	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.4.20-pre10-ac1-machiavel-new/include/linux/netfilter_ipv4/ipt_condition.h	2002-10-25 21:26:09.000000000 -0400
@@ -0,0 +1,11 @@
+#ifndef __IPT_CONDITION_MATCH__
+#define __IPT_CONDITION_MATCH__
+
+#define VARIABLE_NAME_LEN  32
+
+struct condition_info {
+  char	name[VARIABLE_NAME_LEN];
+  int   invert;
+};
+
+#endif
diff -aruN linux-2.4.20-pre10-ac1-machiavel/net/ipv4/netfilter/ipt_condition.c linux-2.4.20-pre10-ac1-machiavel-new/net/ipv4/netfilter/ipt_condition.c
--- linux-2.4.20-pre10-ac1-machiavel/net/ipv4/netfilter/ipt_condition.c	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.4.20-pre10-ac1-machiavel-new/net/ipv4/netfilter/ipt_condition.c	2002-10-25 23:30:15.000000000 -0400
@@ -0,0 +1,227 @@
+/*-------------------------------------------*\
+|          Netfilter Condition Module         |
+|                                             |
+|  Description: This module allows firewall   |
+|    rules to match using condition variables |
+|    stored in /proc files.                   |
+|                                             |
+|  Author: Stephane Ouellette     2002-10-22  |
+|          (ouellettes@videotron.ca)          |
+\*-------------------------------------------*/
+
+#include<linux/module.h>
+#include<linux/proc_fs.h>
+#include<linux/spinlock.h>
+#include<linux/interrupt.h>
+#include<asm/uaccess.h>
+#include<linux/ctype.h>
+#include<linux/vmalloc.h>
+
+#include<linux/netfilter_ipv4/ip_tables.h>
+#include<linux/netfilter_ipv4/ipt_condition.h>
+
+
+MODULE_AUTHOR("Stephane Ouellette <ouellettes@videotron.ca>");
+MODULE_DESCRIPTION("Allows rules to match against condition variables");
+MODULE_LICENSE("GPL");
+
+
+struct condition_variable {
+  char         name[VARIABLE_NAME_LEN];
+			   // Variable Name (NULL-terminated string)
+  u_int32_t    refcount;   // Number of references to this variable
+  u_int32_t    boolean;    // TRUE == 1, FALSE == 0
+  spinlock_t   variable_lock;
+  struct proc_dir_entry *status_proc;
+  struct condition_variable *next;
+};
+
+
+static spinlock_t list_lock = SPIN_LOCK_UNLOCKED;
+static struct condition_variable *head = NULL;
+static struct proc_dir_entry *proc_net_condition = NULL;
+
+
+static int ipt_condition_read_info(char *buffer, char **start, off_t offset,
+int length, int *eof, void *data)
+{
+  if(offset == 0)
+  {
+    *start = buffer;
+    buffer[0] = '0' + (char)((struct condition_variable*)data)->boolean;
+    buffer[1] = '\n';
+    return 2;
+  }
+ 
+  *eof = 1;
+  return 0;
+}
+
+
+static int ipt_condition_write_info(struct file *file, const char *buffer,
+unsigned long length, void *data)
+{
+  if(length)
+  {
+    // Match only on the first character
+    if(buffer[0] == '0')
+      ((struct condition_variable*)data)->boolean = 0;
+    else if(buffer[0] == '1') 
+      ((struct condition_variable*)data)->boolean = 1;
+  }
+
+  return length;
+}
+
+
+static int match(const struct sk_buff *skb, const struct net_device *in,
+const struct net_device *out, const void *matchinfo, int offset,
+const void *hdr, u_int16_t datalen, int *hotdrop)
+{
+  const struct condition_info *info = (const struct condition_info*)matchinfo;
+  struct condition_variable *var = head;
+  
+  while(var && strncmp(info->name, var->name, VARIABLE_NAME_LEN))
+    var = var->next;
+
+  return((var) ? var->boolean ^ info->invert : 0);
+}
+
+
+static int checkentry(const char *tablename, const struct ipt_ip *ip,
+void *matchinfo, unsigned int matchsize, unsigned int hook_mask)
+{
+  struct condition_info *info = (struct condition_info*)matchinfo;
+  struct condition_variable *var, *previous;
+
+  if(matchsize != IPT_ALIGN(sizeof(struct condition_info)))
+    return 0;
+
+  var = head;
+  previous = NULL;
+  spin_lock_bh(&list_lock);
+
+  // Search for the condition variable in the list
+  while(var && (strncmp(info->name, var->name, VARIABLE_NAME_LEN))) 
+  {
+    previous = var;
+    var = var->next;
+  }
+
+  if(var)
+  {
+    // The variable already exists, increment the reference count
+    spin_lock_bh(&var->variable_lock);
+    var->refcount++;    
+    spin_unlock_bh(&var->variable_lock);
+  }
+  else
+  {
+    // Create a new variable 
+    if((var = vmalloc(sizeof(struct condition_variable))) == NULL)
+    {
+      spin_unlock_bh(&list_lock);
+      return -ENOMEM;
+    }
+
+    strncpy(var->name, info->name, VARIABLE_NAME_LEN - 1);
+    var->name[VARIABLE_NAME_LEN - 1] = 0;
+    var->refcount = 1;
+    var->boolean = 0;
+    var->variable_lock = SPIN_LOCK_UNLOCKED;
+    var->next = NULL;
+    var->status_proc = create_proc_entry(var->name, 0644, proc_net_condition);
+
+    if(!var->status_proc)
+    {
+      vfree(var);
+      spin_unlock_bh(&list_lock);
+      return -ENOMEM;
+    }
+
+    var->status_proc->owner = THIS_MODULE;
+    var->status_proc->read_proc = ipt_condition_read_info;
+    var->status_proc->write_proc = ipt_condition_write_info;
+    var->status_proc->data = var;
+
+    if(previous)
+      previous->next = var;
+    else
+      head = var;
+  }
+
+  spin_unlock_bh(&list_lock);
+  return 1;
+}
+
+
+static void destroy(void *matchinfo, unsigned int matchsize)
+{
+  struct condition_info *info = (struct condition_info*)matchinfo;
+  struct condition_variable *var, *previous;
+
+  if(matchsize != IPT_ALIGN(sizeof(struct condition_info)))
+    return;
+
+  var = head;
+  previous = NULL;
+  
+  spin_lock_bh(&list_lock);
+
+  while(var && strncmp(info->name, var->name, VARIABLE_NAME_LEN))
+  {
+    previous = var;
+    var = var->next;
+  }
+
+  if(var)
+  {
+    spin_lock_bh(&var->variable_lock);
+
+    if(--var->refcount == 0)
+    {
+      if(previous)
+        previous->next = var->next;
+      else
+        head = var->next;
+
+      remove_proc_entry(var->name, proc_net_condition);
+      spin_unlock_bh(&var->variable_lock);
+      vfree(var);
+    }
+    else spin_unlock_bh(&var->variable_lock);
+  }
+
+  spin_unlock_bh(&list_lock);
+}
+
+
+static struct ipt_match condition_match =
+{ { NULL, NULL }, "condition", &match, &checkentry, &destroy, THIS_MODULE };
+
+
+static int __init init(void)
+{
+  int  errorcode;
+  proc_net_condition = proc_mkdir("ipt_condition", proc_net);
+
+  if(proc_net_condition)
+  {
+    if((errorcode = ipt_register_match(&condition_match)) != 0)
+      remove_proc_entry("ipt_condition", proc_net);
+  }
+  else errorcode = -EACCES;
+
+  return(errorcode);
+}
+
+
+static void __exit fini(void)
+{
+  ipt_unregister_match(&condition_match);
+  remove_proc_entry("ipt_condition", proc_net);
+}
+
+module_init(init);
+module_exit(fini);
+

[-- Attachment #3: condition.patch.config.in --]
[-- Type: text/plain, Size: 178 bytes --]

  dep_tristate '  TOS match support' CONFIG_IP_NF_MATCH_TOS $CONFIG_IP_NF_IPTABLES
  dep_tristate '  condition match support' CONFIG_IP_NF_MATCH_CONDITION $CONFIG_IP_NF_IPTABLES

[-- Attachment #4: condition.patch.configure.help --]
[-- Type: text/plain, Size: 290 bytes --]

CONFIG_IP_NF_MATCH_TOS
condition match support
CONFIG_IP_NF_MATCH_CONDITION
  This option allows you to match firewall rules against condition
  variables stored in /proc files.

  If you want to compile it as a module, say M here and read
  Documentation/modules.txt.  If unsure, say `N'.

[-- Attachment #5: condition.patch.help --]
[-- Type: text/plain, Size: 217 bytes --]

Author: Stephane Ouellette <ouellettes@videotron.ca>
Status: ItWorksForMe(tm)

This patch adds CONFIG_IP_NF_MATCH_CONDITION which allows you to
match firewall rules against condition variables stored in /proc files.


[-- Attachment #6: condition.patch.makefile --]
[-- Type: text/plain, Size: 100 bytes --]

obj-$(CONFIG_IP_NF_MATCH_TOS) += ipt_tos.o

obj-$(CONFIG_IP_NF_MATCH_CONDITION) += ipt_condition.o


[-- Attachment #7: libipt_condition.c --]
[-- Type: text/plain, Size: 2099 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <getopt.h>
#include <iptables.h>

#include<linux/netfilter_ipv4/ip_tables.h>
#include<linux/netfilter_ipv4/ipt_condition.h>


static void help(void)
{
  printf("condition match v%s options:\n"
  "--condition [!] filename       Match on boolean value stored in /proc file"
  "\n", IPTABLES_VERSION);
}

static struct option opts[] = { { "condition", 1, 0, 'X' }, { 0 } };

static void init(struct ipt_entry_match *m, unsigned int *nfcache)
{
  *nfcache |= NFC_UNKNOWN;
}

static int parse(int c, char **argv, int invert, unsigned int *flags,
		const struct ipt_entry *entry, unsigned int *nfcache,
		struct ipt_entry_match **match)
{
  struct condition_info *info = (struct condition_info*)(*match)->data;

  check_inverse(optarg, &invert, &optind, 0);

  if(*flags)
    exit_error(PARAMETER_PROBLEM, "Can't specify multiple conditions");

  if(c == 'X')
  {
    if(strlen(argv[optind-1]) < VARIABLE_NAME_LEN)
      strcpy(info->name, argv[optind-1]);
    else
      exit_error(PARAMETER_PROBLEM, "File name too long");

    info->invert = invert;
    *flags = 1;
    return 1;
  }

  return 0;
}


static void final_check(unsigned int flags)
{
  if(!flags)
    exit_error(PARAMETER_PROBLEM, "Condition match: must specify --condition");
}


static void print(const struct ipt_ip *ip,
		const struct ipt_entry_match *match, int numeric)
{
  const struct condition_info *info = (const struct condition_info*)match->data;

  printf("condition %s%s ", (info->invert) ? "!" : "", info->name);
}


static void save(const struct ipt_ip *ip, const struct ipt_entry_match *match)
{
  const struct condition_info *info = (const struct condition_info*)match->data;

  printf("--condition %s%s ", (info->invert) ? "! " : "", info->name);
}


static struct iptables_match condition = {
  NULL,
  "condition",
  IPTABLES_VERSION,
  IPT_ALIGN(sizeof(struct condition_info)),
  IPT_ALIGN(sizeof(struct condition_info)),
  &help,
  &init,
  &parse,
  &final_check,
  &print,
  &save,
  opts
};


void _init(void)
{
  register_match(&condition);
}

Re: [NEW EXTENSION] Condition Match

[Brad Chapman]

Mr. Oullette,

--- Stephane Ouellette <ouellettes@videotron.ca> wrote:
> Folks,
> 
>    I developped last week a new extension to Netfilter in order to 
> enable or disable a set of rules using /proc files.
> 
>    As an example, I like to play Quake III Aerna with a few friends of 
> mine but I don't want to keep the firewall rules that make them able to 
> connect to my computer active at all times.  Adding and removing these 
> specific rules is annoying...
> 
>     So my solution is illustrated by the following rules:
> 
> iptables -t nat -A PREROUTING -p udp -m condition -i $INTERNET --dport 
> 27960 --condition quake -j DNAT --to-destination $MYCOMPUTER
> iptables -t filter -A FORWARD -p udp -m condition -i $INTERNET -o $LAN 
> --dport 27960 --condition quake -j ACCEPT
> iptables -t filter -A FORWARD -p udp -m condition -i $LAN -o $INTERNET 
> --dport 27960 --condition quake -j ACCEPT
> 
> 
> To enable the rules, issue:        echo 1 > /proc/net/ipt_condition/quake
> To disable the rules, issue:       echo 0> /proc/net/ipt_condition/quake

Useful. I can think of dozens of different uses for soemthing like this.

> 
> 
> The /proc files are created automagically when a new condition is 
> defined and destroyed when no rule points to them anymore.
> 
> As of this writing, the condition match module supports only one 
> condition per rule.  I think I will add in a near future the possibility 
> to match on many conditions at the same time, using the syntax:     
> --condition file1,file2,file3. . .

IMO you should be careful here. Adding too many of these just clutters things up
and makes it hard to understand.

> 
> - It was tested under kernel 2.4.20-pre10-ac2
> - So far so good, the condition match module seems stable !
> 
> Any comments, bug reports or suggestions would be greatly appreciated.

One suggestion: take a look at iptables2 and code up a patch for this which uses
netlink to check&control the conditions. Also, try a patch for IPv6, IMHO.

> 
> Enjoy !
> 
> Stephane.
> 

Brad

=====
Brad Chapman

Permanent e-mail: kakadu_croc@yahoo.com

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: [NEW EXTENSION] Condition Match

[Robin Johnson]

Stephane Ouellette wrote:
> To enable the rules, issue:        echo 1 > /proc/net/ipt_condition/quake
> To disable the rules, issue:       echo 0> /proc/net/ipt_condition/quake
Just one suggestion with this, is /proc/net the right part of /proc for this?
/proc/net seems to be statistics reporting only, with /proc/net/sys/ipv{4,6} 
being where options are controlled.

> As of this writing, the condition match module supports only one 
> condition per rule.  I think I will add in a near future the possibility 
> to match on many conditions at the same time, using the syntax:     
> --condition file1,file2,file3. . .
This may be getting somewhat complex, but would it be possible to have binary 
ops on the conditions?
eg: --condition file1 --conditionand file2 etc. But this MIGHT be getting a 
little complex IMHO ;-).

Other than that, it looks like a wonderful idea to be able to turn off/on rules 
as needed.

Re: [NEW EXTENSION] Condition Match

[allen]

On Tuesday 29 October 2002 12:54 pm, Stephane Ouellette wrote:
>    I developped last week a new extension to Netfilter in order to
> enable or disable a set of rules using /proc files.


Yeah, as others have said, the idea is definitely cool.

I hate to admit that I might use it this way.  God help me...

I'm having visions of debugging impossibly complex
booboo's, and chasing after phantom problems that
appear and disappear and not remembering that
I or someone had done or could have done this.

Can you think of a way to implement far greater
"manageability"

?

Or what are your thoughts about that ?

Maybe it is a "user-be-ware" thing best left to
some odd application to keep track of.

Hmn...

But... the "rules" would appear though... right ?

With an "iptables -L" ?

And current "state" ?

-AEF

Re: [NEW EXTENSION] Condition Match

[Harald Welte]

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

On Tue, Oct 29, 2002 at 10:43:07PM -0600, allen wrote:
> 
> 
> On Tuesday 29 October 2002 12:54 pm, Stephane Ouellette wrote:
> >    I developped last week a new extension to Netfilter in order to
> > enable or disable a set of rules using /proc files.
> 
> 
> Yeah, as others have said, the idea is definitely cool.

Though the idea is cool, I think we are solving a problem the wrong way.  Why
add complexity to the kernel for a problem which can be solved without
any problem from userspace?

Where is the problem in having a couple of different rulesets (e.g. created
with iptables-save) which are then loaded using an iptables-restore
commandline or a script at the shell of the firewall?


-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

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

Re: [NEW EXTENSION] Condition Match

[Peter Surda]

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

On Wed, Oct 30, 2002 at 10:04:57AM +0100, Harald Welte wrote:
> > >    I developped last week a new extension to Netfilter in order to
> > > enable or disable a set of rules using /proc files.
> > Yeah, as others have said, the idea is definitely cool.
> Though the idea is cool, I think we are solving a problem the wrong way.  Why
> add complexity to the kernel for a problem which can be solved without
> any problem from userspace?
Well, the same would apply to time and pool matches, wouldn't it? They made it
into patch-o-matic though.

> Live long and prosper
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
Bye,

Peter Surda (Shurdeek) <shurdeek@panorama.sth.ac.at>, ICQ 10236103, +436505122023

--
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)

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

Re: [NEW EXTENSION] Condition Match

[Brad Chapman]

Harald,

--- Harald Welte <laforge@gnumonks.org> wrote:
> On Tue, Oct 29, 2002 at 10:43:07PM -0600, allen wrote:
> > 
> > 
> > On Tuesday 29 October 2002 12:54 pm, Stephane Ouellette wrote:
> > >    I developped last week a new extension to Netfilter in order to
> > > enable or disable a set of rules using /proc files.
> > 
> > 
> > Yeah, as others have said, the idea is definitely cool.
> 
> Though the idea is cool, I think we are solving a problem the wrong way.  Why
> add complexity to the kernel for a problem which can be solved without
> any problem from userspace?
> 
> Where is the problem in having a couple of different rulesets (e.g. created
> with iptables-save) which are then loaded using an iptables-restore
> commandline or a script at the shell of the firewall?

Because right now the method of reloading rules is still inefficient. What if you
have a ruleset of 1000-10000 rules and only want to toggle 5? Removing those rules
would require a full replacement of the ruleset for the table and chain the rules
were placed in (IIRC). Doing it this way allows you to disable/enable rules without
having to actually modify them.

Maybe once nfnetlink goes into the 2.7 kernel this will go away, but that's a long
time IMHO.....

> 
> 
> -- 
> Live long and prosper
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/

Brad



=====
Brad Chapman

Permanent e-mail: kakadu_croc@yahoo.com

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: [NEW EXTENSION] Condition Match

[Stephane Ouellette]

allen wrote:

>On Tuesday 29 October 2002 12:54 pm, Stephane Ouellette wrote:
>  
>
>>   I developped last week a new extension to Netfilter in order to
>>enable or disable a set of rules using /proc files.
>>    
>>
>
>
>Yeah, as others have said, the idea is definitely cool.
>
>I hate to admit that I might use it this way.  God help me...
>
>I'm having visions of debugging impossibly complex
>booboo's, and chasing after phantom problems that
>appear and disappear and not remembering that
>I or someone had done or could have done this.
>
>Can you think of a way to implement far greater
>"manageability"
>
>?
>

   I'm not sure to understand your question...   :-(

>
>Or what are your thoughts about that ?
>
>Maybe it is a "user-be-ware" thing best left to
>some odd application to keep track of.
>
>Hmn...
>
>But... the "rules" would appear though... right ?
>
>With an "iptables -L" ?
>  
>

   The rules appear with "iptables -L"  such as :

0   0   ACCEPT      udp    ---    *    *     0.0.0.0/0   0.0.0.0/0   
 condition quake udp dpt:27960

>And current "state" ?
>

   No, the current state is only available if you read the /proc file.

>-AEF
>
>  
>

Re: [NEW EXTENSION] Condition Match

[Harald Welte]

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

On Tue, Oct 29, 2002 at 01:54:06PM -0500, Stephane Ouellette wrote:
> Folks,
> 
>    I developped last week a new extension to Netfilter in order to 
> enable or disable a set of rules using /proc files.

I've added it to patch-o-matic.

btw: you were missing the userspace/extensions/.condition-test script :)

> Enjoy !
> Stephane.
-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

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