All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* New target: can't delete rule
@ 2005-09-07 18:09 Gervasio Bernal
  2005-09-07 22:30 ` Pablo Neira
  0 siblings, 1 reply; 7+ messages in thread
From: Gervasio Bernal @ 2005-09-07 18:09 UTC (permalink / raw
  To: netfilter-devel

Hi all!!!!

I'm from Argentina and I'm developing a new target for iptables with a
college friend. This new target uses the Linux Cryptographic API.

We are debbuging the new extension and we noticed a rare behavior. 
First we inserted the rule like this:
#iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
And we don't have problems. 

The problem appears when we tried to erase the rule:
#iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
It says: :-(
iptables: No chain/target/match by that name

But, if we put this:
#iptables -t mangle -D INPUT 1
It erases correctly :-)

Why it works with a method and not with the another one?
It can be because we allocating memory in checkentry function and
freeing it  in destroy function?
How can we correct this rare behavior?

Thanks a lot.

Gervasio Bernal - Mendoza - Argentina
Pedro Deis - Mendoza - Argentina

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-07 18:09 New target: can't delete rule Gervasio Bernal
@ 2005-09-07 22:30 ` Pablo Neira
  2005-09-07 22:34   ` Patrick McHardy
  2005-09-12 19:23   ` Gervasio Bernal
  0 siblings, 2 replies; 7+ messages in thread
From: Pablo Neira @ 2005-09-07 22:30 UTC (permalink / raw
  To: Gervasio Bernal; +Cc: netfilter-devel

Gervasio Bernal wrote:
> I'm from Argentina and I'm developing a new target for iptables with a
> college friend. This new target uses the Linux Cryptographic API.
> 
> We are debbuging the new extension and we noticed a rare behavior. 
> First we inserted the rule like this:
> #iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> And we don't have problems. 
> 
> The problem appears when we tried to erase the rule:
> #iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> It says: :-(
> iptables: No chain/target/match by that name
> 
> But, if we put this:
> #iptables -t mangle -D INPUT 1
> It erases correctly :-)
> 
> Why it works with a method and not with the another one?
> It can be because we allocating memory in checkentry function and
> freeing it  in destroy function?
> How can we correct this rare behavior?

I bet that you have a pointer in the private info section of the target. 
See that iptables sets that pointer to NULL at rule creation. 
Afterwards, once checkentry() is called, such pointer won't be NULL anymore.

At removal, the rule built by iptables sets that pointer to NULL. Such 
rule will be compared with the ruleset hold in kernel space but no 
matches will be found since the pointers mismatch.

This problem is well known and it's very easy to fix up (look for 
userspacesize and offsetof in iptables/extensions). See ipt_limit, 
ipt_CLUSTERIP...

But it's *even* easier to figure out what's wrong with yout module if 
you post it here, in the mailing list.

--
Pablo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-07 22:30 ` Pablo Neira
@ 2005-09-07 22:34   ` Patrick McHardy
  2005-09-07 23:58     ` Pablo Neira
  2005-09-12 19:23   ` Gervasio Bernal
  1 sibling, 1 reply; 7+ messages in thread
From: Patrick McHardy @ 2005-09-07 22:34 UTC (permalink / raw
  To: Pablo Neira; +Cc: Gervasio Bernal, netfilter-devel

Pablo Neira wrote:
> I bet that you have a pointer in the private info section of the target.
> See that iptables sets that pointer to NULL at rule creation.
> Afterwards, once checkentry() is called, such pointer won't be NULL
> anymore.
> 
> At removal, the rule built by iptables sets that pointer to NULL. Such
> rule will be compared with the ruleset hold in kernel space but no
> matches will be found since the pointers mismatch.
> 
> This problem is well known and it's very easy to fix up (look for
> userspacesize and offsetof in iptables/extensions). See ipt_limit,
> ipt_CLUSTERIP...

Thanks, I didn't know about this problem. We should really focus on
a netlink interface to iptables once nf_conntrack is in, even without
pkttables.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-07 22:34   ` Patrick McHardy
@ 2005-09-07 23:58     ` Pablo Neira
  0 siblings, 0 replies; 7+ messages in thread
From: Pablo Neira @ 2005-09-07 23:58 UTC (permalink / raw
  To: Patrick McHardy; +Cc: Gervasio Bernal, netfilter-devel

Patrick McHardy wrote:
> Thanks, I didn't know about this problem. We should really focus on
> a netlink interface to iptables once nf_conntrack is in, even without
> pkttables.

Should be really worthy the effort of implementing such netlink 
interface for iptables? I'm not too convinced. It'd be better if we 
spend our time implementing pkttables on top of netlink since it's meant 
to supersede all the functionalties provided by iptables. Anyway, I 
expect that there will be time to discuss this stuff during the workshop ;)

--
Pablo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-07 22:30 ` Pablo Neira
  2005-09-07 22:34   ` Patrick McHardy
@ 2005-09-12 19:23   ` Gervasio Bernal
  2005-09-12 23:24     ` Pablo Neira
  1 sibling, 1 reply; 7+ messages in thread
From: Gervasio Bernal @ 2005-09-12 19:23 UTC (permalink / raw
  To: Pablo Neira; +Cc: netfilter-devel

El mié, 07-09-2005 a las 22:30, Pablo Neira escribió:
> Gervasio Bernal wrote:
> > I'm from Argentina and I'm developing a new target for iptables with a
> > college friend. This new target uses the Linux Cryptographic API.
> > 
> > We are debbuging the new extension and we noticed a rare behavior. 
> > First we inserted the rule like this:
> > #iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> > And we don't have problems. 
> > 
> > The problem appears when we tried to erase the rule:
> > #iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> > It says: :-(
> > iptables: No chain/target/match by that name
> > 
> > But, if we put this:
> > #iptables -t mangle -D INPUT 1
> > It erases correctly :-)
> > 
> > Why it works with a method and not with the another one?
> > It can be because we allocating memory in checkentry function and
> > freeing it  in destroy function?
> > How can we correct this rare behavior?
> 
> I bet that you have a pointer in the private info section of the target. 
> See that iptables sets that pointer to NULL at rule creation. 
> Afterwards, once checkentry() is called, such pointer won't be NULL anymore.
> 
> At removal, the rule built by iptables sets that pointer to NULL. Such 
> rule will be compared with the ruleset hold in kernel space but no 
> matches will be found since the pointers mismatch.
> 
> This problem is well known and it's very easy to fix up (look for 
> userspacesize and offsetof in iptables/extensions). See ipt_limit, 
> ipt_CLUSTERIP...
> 
> But it's *even* easier to figure out what's wrong with yout module if 
> you post it here, in the mailing list.
> 
> --
> Pablo
> 

Pablo: 
    I did what you said, but I cannot make walk it. 

This is my libipt_CRYPT.c 

static struct iptables_target CRYPT 
= { 
    .name            = "CRYPT", 
    .version         = IPTABLES_VERSION, 
    .size            = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)), 
    .userspacesize   = offsetof(struct ipt_CRYPT_info,
table_alloc_ptr),        
    .help            = &help, 
    .init            = &init, 
    .parse           = &parse, 
    .final_check     = &final_check, 
    .print           = &print, 
    .save            = &save, 
    .extra_opts      = opts 
}; 


This is my ipt_CRYPT.h 

struct ipt_CRYPT_info 
{ 
        char key[MAX_KEY_SIZE]; 
        unsigned int block_size; 
        unsigned int key_size; 

        struct tabla_alloc* table_alloc_ptr; 
}; 

struct tabla_alloc 
{ 
        struct crypto_tfm *tfm; 
        struct tabla_alloc* next; 
        struct tabla_alloc* ant; 
}; 

Greetings 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-12 23:24     ` Pablo Neira
@ 2005-09-12 20:45       ` Gervasio Bernal
  0 siblings, 0 replies; 7+ messages in thread
From: Gervasio Bernal @ 2005-09-12 20:45 UTC (permalink / raw
  To: Pablo Neira; +Cc: netfilter-devel

Pablo Neira wrote:
> Gervasio Bernal wrote:
> 
>>     I did what you said, but I cannot make walk it.
>> This is my libipt_CRYPT.c
>> static struct iptables_target CRYPT = {     .name            =
>> "CRYPT",     .version         = IPTABLES_VERSION,     .size           
>> = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)),     .userspacesize   =
>> offsetof(struct ipt_CRYPT_info,
>> table_alloc_ptr),            .help            = &help,    
>> .init            = &init,     .parse           = &parse,    
>> .final_check     = &final_check,     .print           = &print,    
>> .save            = &save,     .extra_opts      = opts };
>>
>> This is my ipt_CRYPT.h
>> struct ipt_CRYPT_info {         char key[MAX_KEY_SIZE];        
>> unsigned int block_size;         unsigned int key_size;
>>         struct tabla_alloc* table_alloc_ptr; };
>> struct tabla_alloc {         struct crypto_tfm *tfm;         struct
>> tabla_alloc* next;         struct tabla_alloc* ant; }; 
> 
> 
> It looks fine. Which iptables version are you using? If my mind servers
> well, I remember that there was a bug related with targets and the use
> of userspacesize in old iptables versions (<= 1.3.1). If so, please try
> with the lastest update.
> 
> -- 
> Pablo
> 

Yes, I have iptables version 1.3.1. I will try with one newer and I
comment to you.
Thanks again

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: New target: can't delete rule
  2005-09-12 19:23   ` Gervasio Bernal
@ 2005-09-12 23:24     ` Pablo Neira
  2005-09-12 20:45       ` Gervasio Bernal
  0 siblings, 1 reply; 7+ messages in thread
From: Pablo Neira @ 2005-09-12 23:24 UTC (permalink / raw
  To: Gervasio Bernal; +Cc: netfilter-devel

Gervasio Bernal wrote:
>     I did what you said, but I cannot make walk it. 
> 
> This is my libipt_CRYPT.c 
> 
> static struct iptables_target CRYPT 
> = { 
>     .name            = "CRYPT", 
>     .version         = IPTABLES_VERSION, 
>     .size            = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)), 
>     .userspacesize   = offsetof(struct ipt_CRYPT_info,
> table_alloc_ptr),        
>     .help            = &help, 
>     .init            = &init, 
>     .parse           = &parse, 
>     .final_check     = &final_check, 
>     .print           = &print, 
>     .save            = &save, 
>     .extra_opts      = opts 
> }; 
> 
> 
> This is my ipt_CRYPT.h 
> 
> struct ipt_CRYPT_info 
> { 
>         char key[MAX_KEY_SIZE]; 
>         unsigned int block_size; 
>         unsigned int key_size; 
> 
>         struct tabla_alloc* table_alloc_ptr; 
> }; 
> 
> struct tabla_alloc 
> { 
>         struct crypto_tfm *tfm; 
>         struct tabla_alloc* next; 
>         struct tabla_alloc* ant; 
> }; 

It looks fine. Which iptables version are you using? If my mind servers
well, I remember that there was a bug related with targets and the use
of userspacesize in old iptables versions (<= 1.3.1). If so, please try
with the lastest update.

--
Pablo

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-09-12 23:24 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-07 18:09 New target: can't delete rule Gervasio Bernal
2005-09-07 22:30 ` Pablo Neira
2005-09-07 22:34   ` Patrick McHardy
2005-09-07 23:58     ` Pablo Neira
2005-09-12 19:23   ` Gervasio Bernal
2005-09-12 23:24     ` Pablo Neira
2005-09-12 20:45       ` Gervasio Bernal

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.