ebtables issue in compat mode

ebtables issue in compat mode

[Sharat Masetty]

I am seeing a problem when running ebtables in 32bit userspace and 64
bit kernel space mode.

The command I am trying to run is
ebtables -t broute -A BROUTING -p IPv4 -j DROP

Here is the log message I am seeing in userspace

The message (http://sourceforge.net/p/ebtables/code/ci/master/tree/userspace/ebtables2/communication.c
Line 243) in userspace is

        ebt_print_error("Unable to update the kernel. Two possible causes:\n"

                       "1. Multiple ebtables programs were executing
simultaneously. The ebtables\n"

                       "   userspace tool doesn't by default support
multiple ebtables programs running\n"

                       "   concurrently. The ebtables option
--concurrent or a tool like flock can be\n"

                       "   used to support concurrent scripts that
update the ebtables kernel tables.\n"

                       "2. The kernel doesn't support a certain
ebtables extension, consider\n"

                       "   recompiling your kernel or insmod the extension.\n");

I noticed that setsockopt() is failing . The message is also printed
in kernel – Standard target size too big . This occurs because there
is a mismatch in the size of the structures ebt_standard_target which
is 48 bytes in kernel and 40 bytes in userspace.

Can someone help us fix this issue?

Thanks
Sharat
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables issue in compat mode

[Florian Westphal]

Sharat Masetty <sharat04@gmail.com> wrote:
> I am seeing a problem when running ebtables in 32bit userspace and 64
> bit kernel space mode.
> 
> The command I am trying to run is
> ebtables -t broute -A BROUTING -p IPv4 -j DROP
> 
> Here is the log message I am seeing in userspace
> 
[..]

> I noticed that setsockopt() is failing . The message is also printed
> in kernel – Standard target size too big . This occurs because there
> is a mismatch in the size of the structures ebt_standard_target which
> is 48 bytes in kernel and 40 bytes in userspace.
> 
> Can someone help us fix this issue?

Please provide more information.

Works fine for me on x86_64 with 32 bit binary:
# ~/bin32/ebtables -t broute -A BROUTING -p IPv4 -j DROP
# echo $?
0
ebtables -L shows
Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p IPv4 -j DROP 

as expected.  Linux 3.13.11 x86_64.

Are you using an old kernel without ebt compat support?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables issue in compat mode

[Sharat Masetty]

We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
I also have another question. Do we need to compile the userspace tool
using the sanitized kernel headers?(uapi/linux) or should we be using
headers provided in the ebtables user space package? The reason for
asking this question is that I see some differences in the structure
definitions between the ebtables packaged kernel header files and the
header files exposed by the kernel.

Please let me know what to watch out for

Thanks
Sharat

On Thu, May 1, 2014 at 4:02 AM, Florian Westphal <fw@strlen.de> wrote:
> Sharat Masetty <sharat04@gmail.com> wrote:
>> I am seeing a problem when running ebtables in 32bit userspace and 64
>> bit kernel space mode.
>>
>> The command I am trying to run is
>> ebtables -t broute -A BROUTING -p IPv4 -j DROP
>>
>> Here is the log message I am seeing in userspace
>>
> [..]
>
>> I noticed that setsockopt() is failing . The message is also printed
>> in kernel – Standard target size too big . This occurs because there
>> is a mismatch in the size of the structures ebt_standard_target which
>> is 48 bytes in kernel and 40 bytes in userspace.
>>
>> Can someone help us fix this issue?
>
> Please provide more information.
>
> Works fine for me on x86_64 with 32 bit binary:
> # ~/bin32/ebtables -t broute -A BROUTING -p IPv4 -j DROP
> # echo $?
> 0
> ebtables -L shows
> Bridge chain: BROUTING, entries: 1, policy: ACCEPT
> -p IPv4 -j DROP
>
> as expected.  Linux 3.13.11 x86_64.
>
> Are you using an old kernel without ebt compat support?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables issue in compat mode

[Sharat Masetty]

Just a quick update, We are actually using kernel sanitized headers
for compilation, and we still see the same issue

Here is where it is failing exactly, in check_chainloops() function in
ebtables.c in the kernel

if (e->target_offset + sizeof(struct ebt_standard_target) >
e->next_offset) {
BUGPRINT("Standard target size too big\n");
return -1;
}

Thanks
Sharat

On Thu, May 1, 2014 at 10:09 AM, Sharat Masetty <sharat04@gmail.com> wrote:
> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
> I also have another question. Do we need to compile the userspace tool
> using the sanitized kernel headers?(uapi/linux) or should we be using
> headers provided in the ebtables user space package? The reason for
> asking this question is that I see some differences in the structure
> definitions between the ebtables packaged kernel header files and the
> header files exposed by the kernel.
>
> Please let me know what to watch out for
>
> Thanks
> Sharat
>
> On Thu, May 1, 2014 at 4:02 AM, Florian Westphal <fw@strlen.de> wrote:
>> Sharat Masetty <sharat04@gmail.com> wrote:
>>> I am seeing a problem when running ebtables in 32bit userspace and 64
>>> bit kernel space mode.
>>>
>>> The command I am trying to run is
>>> ebtables -t broute -A BROUTING -p IPv4 -j DROP
>>>
>>> Here is the log message I am seeing in userspace
>>>
>> [..]
>>
>>> I noticed that setsockopt() is failing . The message is also printed
>>> in kernel – Standard target size too big . This occurs because there
>>> is a mismatch in the size of the structures ebt_standard_target which
>>> is 48 bytes in kernel and 40 bytes in userspace.
>>>
>>> Can someone help us fix this issue?
>>
>> Please provide more information.
>>
>> Works fine for me on x86_64 with 32 bit binary:
>> # ~/bin32/ebtables -t broute -A BROUTING -p IPv4 -j DROP
>> # echo $?
>> 0
>> ebtables -L shows
>> Bridge chain: BROUTING, entries: 1, policy: ACCEPT
>> -p IPv4 -j DROP
>>
>> as expected.  Linux 3.13.11 x86_64.
>>
>> Are you using an old kernel without ebt compat support?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables issue in compat mode

[Florian Westphal]

Sharat Masetty <sharat04@gmail.com> wrote:
> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.

FWIW i have no issues with 2.0.10-4 either (on x86), so its hard
for me to debug this since I don't have access to a aarch64/arm64
machine.

> Please let me know what to watch out for

My guess would be that ebt_size_mwt() in size_entry_mwt() fails
to account for some required padding.

You could #define DEBUG at the top of it and see the offset
fixup that it tries to make.

Should be fairly simple to build a ebtables64 binary
and check what the expected values should be.

Re: ebtables issue in compat mode

[Jan Engelhardt]

On Saturday 2014-05-03 00:31, Florian Westphal wrote:

>Sharat Masetty <sharat04@gmail.com> wrote:
>> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
>> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
>
>FWIW i have no issues with 2.0.10-4 either (on x86), so its hard
>for me to debug this since I don't have access to a aarch64/arm64
>machine.

This has occurred so regularly now that it's likely to be one and the 
same ABI issue all again where some user has more than 2 ABIs in the 
system.

Re: ebtables issue in compat mode

[Florian Westphal]

Jan Engelhardt <jengelh@inai.de> wrote:
> On Saturday 2014-05-03 00:31, Florian Westphal wrote:
> 
> >Sharat Masetty <sharat04@gmail.com> wrote:
> >> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
> >> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
> >
> >FWIW i have no issues with 2.0.10-4 either (on x86), so its hard
> >for me to debug this since I don't have access to a aarch64/arm64
> >machine.
> 
> This has occurred so regularly now that it's likely to be one and the 
> same ABI issue all again where some user has more than 2 ABIs in the 
> system.

I must have missed something, what are you refering to?

Re: ebtables issue in compat mode

[Sharat Masetty]

Thanks for the suggestions, I will dig into it and see if I can
provide relevant logs here.

Do we have to enabled this define in the userspace?
KERNEL_64_USERSPACE_32, Tried enabling it and it fails at some other
location in the kernel. So its unclear whether to enable this or
not...

Thanks
Sharat

On Fri, May 2, 2014 at 4:37 PM, Florian Westphal <fw@strlen.de> wrote:
> Jan Engelhardt <jengelh@inai.de> wrote:
>> On Saturday 2014-05-03 00:31, Florian Westphal wrote:
>>
>> >Sharat Masetty <sharat04@gmail.com> wrote:
>> >> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
>> >> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
>> >
>> >FWIW i have no issues with 2.0.10-4 either (on x86), so its hard
>> >for me to debug this since I don't have access to a aarch64/arm64
>> >machine.
>>
>> This has occurred so regularly now that it's likely to be one and the
>> same ABI issue all again where some user has more than 2 ABIs in the
>> system.
>
> I must have missed something, what are you refering to?

Re: ebtables issue in compat mode

[Bart De Schuymer]

Sharat Masetty schreef op 3/05/2014 3:06:
> Thanks for the suggestions, I will dig into it and see if I can
> provide relevant logs here.
>
> Do we have to enabled this define in the userspace?
> KERNEL_64_USERSPACE_32, Tried enabling it and it fails at some other
> location in the kernel. So its unclear whether to enable this or
> not...

That option was introduced and has only been tested for Sparc32/64, so 
odds are it doesn't work for your setup (note that you need the 
ebtables.h version that comes with the ebtables userspace package). But 
a hack similar to that will probably make it work for you (it's a matter 
of getting the offsets of the struct members right and translating 
32-bit pointers into 64-bit pointers). I thought the whole compat layer 
would make this stuff irrelevant. Guess not.

cheers,
Bart

Re: ebtables issue in compat mode

[Jan Engelhardt]

On Saturday 2014-05-03 00:37, Florian Westphal wrote:
>> >Sharat Masetty <sharat04@gmail.com> wrote:
>> >> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
>> >> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
>> >
>> >FWIW i have no issues with 2.0.10-4 either (on x86), so its hard
>> >for me to debug this since I don't have access to a aarch64/arm64
>> >machine.
>> 
>> This has occurred so regularly now that it's likely to be one and the 
>> same ABI issue all again where some user has more than 2 ABIs in the 
>> system.
>
>I must have missed something, what are you refering to?

Oh, my post from April 18.
http://www.spinics.net/lists/netfilter-devel/msg31526.html

I also found http://bugs.debian.org/690548 in my archives, as an example 
where the same occurred with a MIPS box.


As for x86, if i386 and x32 did not have the same alignment, it would 
probably also show on x86.

Re: ebtables issue in compat mode

[Bart De Schuymer]

Sharat Masetty schreef op 1/05/2014 18:09:
> We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
> The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.
> I also have another question. Do we need to compile the userspace tool
> using the sanitized kernel headers?(uapi/linux) or should we be using
> headers provided in the ebtables user space package? The reason for
> asking this question is that I see some differences in the structure
> definitions between the ebtables packaged kernel header files and the
> header files exposed by the kernel.

The kernel should be backwards compatible, so using the provided header 
files should be fine.

cheers,
Bart

ebtables issue in compat mode

[Sharat Masetty]

I am seeing a problem when running ebtables in 32bit userspace and 64
bit kernel space mode.

The command I am trying to run is
ebtables -t broute -A BROUTING -p IPv4 -j DROP

Here is the log message I am seeing in userspace

The message (http://sourceforge.net/p/ebtables/code/ci/master/tree/userspace/ebtables2/communication.c
Line 243) in userspace is

        ebt_print_error("Unable to update the kernel. Two possible causes:\n"

                       "1. Multiple ebtables programs were executing
simultaneously. The ebtables\n"

                       "   userspace tool doesn't by default support
multiple ebtables programs running\n"

                       "   concurrently. The ebtables option
--concurrent or a tool like flock can be\n"

                       "   used to support concurrent scripts that
update the ebtables kernel tables.\n"

                       "2. The kernel doesn't support a certain
ebtables extension, consider\n"

                       "   recompiling your kernel or insmod the extension.\n");

I noticed that setsockopt() is failing . The message is also printed
in kernel – Standard target size too big . This occurs because there
is a mismatch in the size of the structures ebt_standard_target which
is 48 bytes in kernel and 40 bytes in userspace.
We are using a 3.10.0 kernel version which has CONFIG_COMPAT enabled.
The ebtables version is 2.0.10-4.  This is arm 63/32 not x86.


Here is where it is failing exactly, in check_chainloops() function in
ebtables.c in the kernel

if (e->target_offset + sizeof(struct ebt_standard_target) >
e->next_offset) {
BUGPRINT("Standard target size too big\n");
return -1;
}


Thanks
Sharat