I have a kernel with
CONFIG_IP_NF_TABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_LOG=y
all other NF options are off.
During kernel startup I get
iptables: loop hook 1 pos 00000022
when filter tries to register at module_init.
Any ideas why I get this loop?
/Mikael
Mikael Starvik wrote:
> I have a kernel with
>
> CONFIG_IP_NF_TABLES=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_LOG=y
>
> all other NF options are off.
Which iptables/kernel versions are you using?
> During kernel startup I get
> iptables: loop hook 1 pos 00000022
>
> when filter tries to register at module_init.
>
> Any ideas why I get this loop?
Please post your ruleset and the kernel config.
>Which iptables/kernel versions are you using?
2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
same kernelconfig works on ARM. So I have to dig some...
/Mikael
Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
>
>
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
>
> same kernelconfig works on ARM. So I have to dig some...
On which architecture did the error occur? It could be related
to 32 bit compat issues ..
Ok, this is what happens:
iptable_filter sets up initial_table.
The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" }
initializes a xt_entry_target struct. target_size gets the value
0x24 and name "".
This is copied to loc_cpu_entry in iptables.c:ipt_register_table()
and translate_table is called
translate_table calls IPT_ENTRY_ITERATE with the
check_entry_function
check_entry does t->u.kernel.target = target;
On this particular architecture u.user.name and u.kernel.target in
struct xt_entry_target has the same address (because of the union). So
name that was previously "" gets mangled here.
check_entry returns into translate_table which calls mark_source_chains
mark_source_chains compares t->target.u.user.name with
IPT_STANDARD_TARGET. name has been mangled above and the comparision
fails. On my ARM platform name has not been mangled (I guess this is
because target and name doesn't share address by I haven't checked).
So... Is it really correct to modify the target pointer there?
/Mikael
-----Original Message-----
From: Mikael Starvik
Sent: Wednesday, January 10, 2007 12:29 PM
To: 'Patrick McHardy'; Mikael Starvik
Cc: 'Linux Kernel Mailing List'; Edgar Iglesias; 'Netfilter Development
Mailinglist'
Subject: RE: Iptable loop during kernel startup
>Which iptables/kernel versions are you using?
2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
same kernelconfig works on ARM. So I have to dig some...
/Mikael
The architecture is called CRIS. Its a straightforward 32-bit only arch. The
only special about this architecture that it doesn't force any alignment of
data (so a packed struct and an unpacked struct is always the same).
/Mikael
-----Original Message-----
From: Patrick McHardy [mailto:[email protected]]
Sent: Wednesday, January 10, 2007 1:50 PM
To: Mikael Starvik
Cc: 'Linux Kernel Mailing List'; Edgar Iglesias; 'Netfilter Development
Mailinglist'
Subject: Re: Iptable loop during kernel startup
Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
>
>
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The
exact
>
> same kernelconfig works on ARM. So I have to dig some...
On which architecture did the error occur? It could be related
to 32 bit compat issues ..
Mikael Starvik wrote:
> Ok, this is what happens:
>
> iptable_filter sets up initial_table.
> The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" }
> initializes a xt_entry_target struct. target_size gets the value
> 0x24 and name "".
> This is copied to loc_cpu_entry in iptables.c:ipt_register_table()
> and translate_table is called
> translate_table calls IPT_ENTRY_ITERATE with the
> check_entry_function
> check_entry does t->u.kernel.target = target;
>
> On this particular architecture u.user.name and u.kernel.target in
> struct xt_entry_target has the same address (because of the union). So
> name that was previously "" gets mangled here.
>
> check_entry returns into translate_table which calls mark_source_chains
> mark_source_chains compares t->target.u.user.name with
> IPT_STANDARD_TARGET. name has been mangled above and the comparision
> fails. On my ARM platform name has not been mangled (I guess this is
> because target and name doesn't share address by I haven't checked).
>
> So... Is it really correct to modify the target pointer there?
Please try the latest -stable kernel, this should be fixed already.