All of lore.kernel.org
 help / color / mirror / Atom feed
* iptable/netfilter mismatch
@ 2008-10-14  7:40 Jesper Bengtsson
  2008-10-14 12:12 ` Patrick McHardy
  0 siblings, 1 reply; 2+ messages in thread
From: Jesper Bengtsson @ 2008-10-14  7:40 UTC (permalink / raw)
  To: 'netfilter-devel@vger.kernel.org'

Hi,

When running iptables on a CRIS cpu (ETRAX FS/100LX) I have a problem with adding error targets.
I've debugged this problem and I found an iptables/netfilter mismatch.

The structure ipt_error_target is defined in two places:
in the kernel, include/linux/netfilter_ipv4/ip_tables.h
struct ipt_error_target
{
        struct ipt_entry_target target;
        char errorname[IPT_FUNCTION_MAXNAMELEN];
};

and in iptables, libiptc/libiptc.c
struct ipt_error_target
{
        STRUCT_ENTRY_TARGET t;
        char error[TABLE_MAXNAMELEN];
};

Before a patch, claiming to fix things for CRIS
(http://lists.netfilter.org/pipermail/netfilter-devel/2007-January/026659.html),
was applied the two structs above had the same size. After the patch the two structs differ by two
bytes in size and when iptables tries to commit an error target to netfilter, netfilter will discard
it since the target has incorrect size. I believe that this will only occur on architectures that don't use structure alignment, e.g. CRIS.

When modifying the struct in libiptc/libiptc.c like this:

struct ipt_error_target
{
        STRUCT_ENTRY_TARGET t;
        char error[FUNCTION_MAXNAMELEN];
};

I can add error targets on my CRIS system.

I'm a iptables/netfilter newbie and I really can't say for sure if FUNCTION_MAXNAMELEN or TABLE_MAXNAMELEN is the correct length to use in the ipt_error_target structure.

Can anyone shed some light over the ipt_error_target structure?

Thanks,
Jesper

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

* Re: iptable/netfilter mismatch
  2008-10-14  7:40 iptable/netfilter mismatch Jesper Bengtsson
@ 2008-10-14 12:12 ` Patrick McHardy
  0 siblings, 0 replies; 2+ messages in thread
From: Patrick McHardy @ 2008-10-14 12:12 UTC (permalink / raw)
  To: Jesper Bengtsson; +Cc: 'netfilter-devel@vger.kernel.org'

Jesper Bengtsson wrote:
> Hi,
> 
> When running iptables on a CRIS cpu (ETRAX FS/100LX) I have a problem with adding error targets.
> I've debugged this problem and I found an iptables/netfilter mismatch.
> 
> The structure ipt_error_target is defined in two places:
> in the kernel, include/linux/netfilter_ipv4/ip_tables.h
> struct ipt_error_target
> {
>         struct ipt_entry_target target;
>         char errorname[IPT_FUNCTION_MAXNAMELEN];
> };
> 
> and in iptables, libiptc/libiptc.c
> struct ipt_error_target
> {
>         STRUCT_ENTRY_TARGET t;
>         char error[TABLE_MAXNAMELEN];
> };
> 
> Before a patch, claiming to fix things for CRIS
> (http://lists.netfilter.org/pipermail/netfilter-devel/2007-January/026659.html),
> was applied the two structs above had the same size. After the patch the two structs differ by two
> bytes in size and when iptables tries to commit an error target to netfilter, netfilter will discard
> it since the target has incorrect size. I believe that this will only occur on architectures that don't use structure alignment, e.g. CRIS.
> 
> When modifying the struct in libiptc/libiptc.c like this:
> 
> struct ipt_error_target
> {
>         STRUCT_ENTRY_TARGET t;
>         char error[FUNCTION_MAXNAMELEN];
> };
> 
> I can add error targets on my CRIS system.
> 
> I'm a iptables/netfilter newbie and I really can't say for sure if FUNCTION_MAXNAMELEN or TABLE_MAXNAMELEN is the correct length to use in the ipt_error_target structure.
> 
> Can anyone shed some light over the ipt_error_target structure?

The versions I'm looking at uses TABLE_MAXNAMELEN in userspace,
which is 32, and FUNCTION_MAXNAMELEN in the kernel, which is 30.
So yeah, this is still broken. "errorname" is not used within
the kernel at all and the limit of 30 doesn't make any sense,
so the correct fix appears to be to also use 32 within the kernel.

This shouldn't break anything since we align to u64 and the
architectures like CRIS where this causes less than 4 byte alignment
are currently broken, for all others it doesn't have any effect.

Could you send a patch against the latest -git tree please?

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

end of thread, other threads:[~2008-10-14 12:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-14  7:40 iptable/netfilter mismatch Jesper Bengtsson
2008-10-14 12:12 ` Patrick McHardy

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.