ebtables-devel — Development questions, bugs, patches

Re: [Ebtables-devel] Bugs in ebtables-restore extension presence checks and other, suggestion for /proc interface

[Peter V. <pv...@ge...>]

В Чтв, 20/09/2007 в 22:53 +0200, Lech Perczak пишет:   
> Your patch works for me. At the time Gentoo script uses manual config,
> but maybe we can simply fall back for managing every of 3 tables. I've
> modified ebtables-save script for getting tables names from
> command-line, and then falling back to grepping /proc/modules stuff. I
> think the /proc interface will be just nice, but you don't need to hurry
> with it. Patch and files are available on
> http://bugs.gentoo.org/show_bug.cgi?id=189315. I'd like to hear what
> Peter thinks about the thing, but I think we're pretty done by now.

Well, I'd say with some typo fixes and patch you posted in our bugzilla
(attached here too) init script is working here too and I'm going to
commit it now. Thank you, Lech and Bart, for your work.

-- 
Peter.

Re: [Ebtables-devel] Bugs in ebtables-restore extension presence checks and other, suggestion for /proc interface

[Lech P. <leo...@tl...>]

Bart De Schuymer wrote:
>
> The attached patch to the userspace program should solve things.
> The /proc changes will have to wait until later. I'm on holiday for 2
> weeks starting saturday. I'll make a new release tomorrow with this fix
> unless you report another problem...
>
> cheers,
>
> Bart
>   
Your patch works for me. At the time Gentoo script uses manual config,
but maybe we can simply fall back for managing every of 3 tables. I've
modified ebtables-save script for getting tables names from
command-line, and then falling back to grepping /proc/modules stuff. I
think the /proc interface will be just nice, but you don't need to hurry
with it. Patch and files are available on
http://bugs.gentoo.org/show_bug.cgi?id=189315. I'd like to hear what
Peter thinks about the thing, but I think we're pretty done by now. Thanks.

Best regards,

Lech

Re: [Ebtables-devel] Bugs in ebtables-restore extension presence checks and other, suggestion for /proc interface

[Bart De S. <bds...@pa...>]

Op di, 11-09-2007 te 01:11 +0200, schreef Lech Perczak:
> Hi. I'm working on ebtables init script for Gentoo, and I've encountered
> 
> certain problems when trying to control it with ebtables-save and
> 
> ebtables-restore.

The attached patch to the userspace program should solve things.
The /proc changes will have to wait until later. I'm on holiday for 2
weeks starting saturday. I'll make a new release tomorrow with this fix
unless you report another problem...

cheers,

Bart

Re: [Ebtables-devel] Bugs in ebtables-restore extension presence checks and other, suggestion for /proc interface

[Bart De S. <bds...@pa...>]

Op di, 11-09-2007 te 01:11 +0200, schreef Lech Perczak:
> Hi. I'm working on ebtables init script for Gentoo, and I've encountered
> 
> certain problems when trying to control it with ebtables-save and
> 
> ebtables-restore. I'm against using kernel modules on servers, routers
> and bridges, and therefore I've compiled complete ebtables inside the
> kernel. As ebtables-save was querying /proc/modules to get installed
> ebtables extensions, I've patched it to fallback to manual configuration
> when nothing is detected, and it works. But when I try to restore the
> rules and policies, ebtables-restore comes up with strange errors. For
> example, although broute table is enabled, when I try to tell
> ebtables-restore that this table is to be configured, it comes up with
> this message: "The kernel doesn't support a certain ebtables extension,
> consider recompiling your kernel or insmod the extension.". Sometimes I
> get same message not for broute, but for nat table. It was never
> encountered for filter table, like in here:
> 
> router ~ # ebtables-restore
> *filter
> :INPUT ACCEPT
> :FORWARD ACCEPT
> :OUTPUT ACCEPT
> 
> *nat
> :PREROUTING ACCEPT
> :OUTPUT ACCEPT
> :POSTROUTING ACCEPT
> 
> *broute
> The kernel doesn't support a certain ebtables extension, consider
> recompiling your kernel or insmod the extension.
> 
> 
> The next error, is when I try to restore particular rule (this one is
> connected with MAC SNAT - very common use) i get the following:
> 
> router ~ # ebtables-restore
> *filter
> :INPUT ACCEPT
> :FORWARD ACCEPT
> :OUTPUT ACCEPT
> *nat
> :PREROUTING ACCEPT
> :OUTPUT ACCEPT
> :POSTROUTING ACCEPT
> -A POSTROUTING -o wlan0 -j snat --to-src 0:50:fc:48:fb:9b --snat-target
> ACCEPT
> Ebtables: libebtc.c ebt_check_for_loops 1007 :Out of memory.
> 
> When setting this rule manually the bridge behaves as it should and the
> rule produces it's effect. But when I try to restore it it isn't
> written. I haven't any idea for more test cases, but after reading
> ebtables-restore.c I'm sure that these errors don't originate from
> ebtables-restore itself, moreover, the second error states libebtc.c. As
> I think many people don't like using any modules on bridges/routers or
> servers I came up with idea of creating /proc interface showing at least
> supported table names to get rid of manual configuration and/or grepping
> /proc/modules in either Gentoo and script supplied with your package,
> just like in iptables. Bart, What do you think about it?

Sounds good to me. I'll have a look at it after this weekend.
I'll try to reproduce your issue next week too, I can't quite grasp
it...

cheers,
Bart

[Ebtables-devel] Bugs in ebtables-restore extension presence checks and other, suggestion for /proc interface

[Lech P. <leo...@tl...>]

Hi. I'm working on ebtables init script for Gentoo, and I've encountered

certain problems when trying to control it with ebtables-save and

ebtables-restore. I'm against using kernel modules on servers, routers
and bridges, and therefore I've compiled complete ebtables inside the
kernel. As ebtables-save was querying /proc/modules to get installed
ebtables extensions, I've patched it to fallback to manual configuration
when nothing is detected, and it works. But when I try to restore the
rules and policies, ebtables-restore comes up with strange errors. For
example, although broute table is enabled, when I try to tell
ebtables-restore that this table is to be configured, it comes up with
this message: "The kernel doesn't support a certain ebtables extension,
consider recompiling your kernel or insmod the extension.". Sometimes I
get same message not for broute, but for nat table. It was never
encountered for filter table, like in here:

router ~ # ebtables-restore
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT

*nat
:PREROUTING ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT

*broute
The kernel doesn't support a certain ebtables extension, consider
recompiling your kernel or insmod the extension.


The next error, is when I try to restore particular rule (this one is
connected with MAC SNAT - very common use) i get the following:

router ~ # ebtables-restore
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
*nat
:PREROUTING ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A POSTROUTING -o wlan0 -j snat --to-src 0:50:fc:48:fb:9b --snat-target
ACCEPT
Ebtables: libebtc.c ebt_check_for_loops 1007 :Out of memory.

When setting this rule manually the bridge behaves as it should and the
rule produces it's effect. But when I try to restore it it isn't
written. I haven't any idea for more test cases, but after reading
ebtables-restore.c I'm sure that these errors don't originate from
ebtables-restore itself, moreover, the second error states libebtc.c. As
I think many people don't like using any modules on bridges/routers or
servers I came up with idea of creating /proc interface showing at least
supported table names to get rid of manual configuration and/or grepping
/proc/modules in either Gentoo and script supplied with your package,
just like in iptables. Bart, What do you think about it?

Re: [Ebtables-devel] [patch] arptables Makefile cleanup and honour DESTDIR

[Peter V. <pv...@ge...>]

Hello, Bart.

В Срд, 15/08/2007 в 16:28 +0200, Bart De Schuymer пишет:
> Looks good, applied. I'm wondering: don't you want
> $(DESTDIR)$(MANDIR)/man8/arptables.8: arptables.8
> ?

As I told you I've mailed automake mailing list and here is the answer:
http://lists.gnu.org/archive/html/automake/2007-08/msg00102.html
This means that using 
$(DESTDIR)$(MANDIR)/man8/arptables.8: arptables.8
could be better in ebtables case. If you wish to do that, possible
implementation applied.

-- 
Peter.

Re: [Ebtables-devel] [patch] arptables Makefile cleanup and honour DESTDIR

[Peter V. <pv...@ge...>]

=D0=92 =D0=A1=D1=80=D0=B4, 15/08/2007 =D0=B2 16:28 +0200, Bart De Schuymer =
=D0=BF=D0=B8=D1=88=D0=B5=D1=82:=20
> Looks good, applied. I'm wondering: don't you want
>=20
> $(DESTDIR)$(MANDIR)/man8/arptables.8: arptables.8
> 	mkdir -p $(@D)
> 	install -m 0644 -o root -g root $< $@
>=20
> instead of
>=20
> $(MANDIR)/man8/arptables.8: arptables.8
> 	mkdir -p $(DESTDIR)$(@D)
> 	install -m 0644 -o root -g root $< $(DESTDIR)$@
>=20
> ?

I've tried to generate Makefile.in with automake and found that there
are no such things in generated Makefile. So while I do not know the
answer on the question "what is right" I'm sure that for purposes
DESTDIR was supposed to be created
http://www.gnu.org/prep/standards/html_node/DESTDIR.html#DESTDIR
the $(DESTDIR)$(MANDIR) is not required.

> > BTW. arptables-0.0.3-2 does not compiles with the recent kernels. Is
> > there any ETA for new release?
>=20
> I'll release 0.0.3-3 as soon as the above question is resolved :)

Great. I do not think this issue should stop the release. tcpdump,
arpwatch and other projects does not do that, so while may be
$(DESTDIR)$(MANDIR) is better, I do not know this for sure and I'd avoid
doing that in Makefile without getting any answer from really Makefile
gurus. I'll try to ask automake mailing list are there any reasons not
to do that, and report you results. But it's summer now so we'll see if
there will be any answer.=20

--=20
Peter.

[Ebtables-devel] ebtables locking issue

[Abhinav S. <abh...@ya...>]

Hi there,

I am new to ebtables code and looking for some help related to locking and atomicity. I am interested in looking into the packets intercepted by ebtables, extract some information, pass this information to userspace, wait for userspace response and then pass the result back to ebtable code.

Everything seemed to be working fine until i encountered locking issues. In the ebt_do_table code there is a "read_lock_bh" is used. When i try to wait inside this code path after sending info to my userspace tool and before returning NF_ACCEPT or NF_DROP, either the CPU hangs or i get an error "schedule while atomic". I tried out different methods for waiting like "wait_event_timeout"  or busy while loop etc. The problem that I understood is that since read_lock_bh disables CPU preemption and do local_bh_disable, if i wait with something that try to call schedule() I get "schedule while atomic". And, if i do busy waiting it means am stuck for ever as preemption is disabled anyways.

It is like chicken and egg problem. I want to wait and let my userspace process schedule so that I could get response from it but the code path is atomic so i cannot schedule my process. After trying out everything I am clueless as what to do.

Any help in this regard would be appreciated.

Thanks,
Abhinav


       
---------------------------------
 Why delete messages? Unlimited storage is just a click away.

Re: [Ebtables-devel] [patch] arptables Makefile cleanup and honour DESTDIR

[Bart De S. <bds...@pa...>]

Op ma, 13-08-2007 te 16:46 +0400, schreef Peter Volkov:
> Hello, Bart.
> 
> Thank you for applying previous patches. Of course your corrections were
> right. In attachment there is similar patch for arptables Makefile.
> Besides changing DESTDIR, there are other two small changes (I do not
> think worth separate patches):
> 1. It removes completely not used anywhere EXTRAS, EXTRA_INSTALLS and
> $(BINDIR)/arptables.
> 2. Removes -DIPT_LIB_DIR=\"$(IPT_LIBDIR)\" as it is not used anywhere
> else in the code.

Looks good, applied. I'm wondering: don't you want

$(DESTDIR)$(MANDIR)/man8/arptables.8: arptables.8
	mkdir -p $(@D)
	install -m 0644 -o root -g root $< $@

instead of

$(MANDIR)/man8/arptables.8: arptables.8
	mkdir -p $(DESTDIR)$(@D)
	install -m 0644 -o root -g root $< $(DESTDIR)$@

?

> BTW. arptables-0.0.3-2 does not compiles with the recent kernels. Is
> there any ETA for new release?

I'll release 0.0.3-3 as soon as the above question is resolved :)

cheers,
Bart

[Ebtables-devel] [patch] arptables Makefile cleanup and honour DESTDIR

[Peter V. <pv...@ge...>]

Hello, Bart.

Thank you for applying previous patches. Of course your corrections were
right. In attachment there is similar patch for arptables Makefile.
Besides changing DESTDIR, there are other two small changes (I do not
think worth separate patches):
1. It removes completely not used anywhere EXTRAS, EXTRA_INSTALLS and
$(BINDIR)/arptables.
2. Removes -DIPT_LIB_DIR=\"$(IPT_LIBDIR)\" as it is not used anywhere
else in the code.

BTW. arptables-0.0.3-2 does not compiles with the recent kernels. Is
there any ETA for new release?

-- 
Peter.

Re: [Ebtables-devel] [patch] DESTDIR does not handeled properly.

[Bart De S. <bds...@pa...>]

Op zo, 12-08-2007 te 14:48 +0400, schreef Peter Volkov:
> Hello.
> 
> ebtables build system (Makefile :) ) currently does not handle DESTDIR
> correctly. DESTDIR is the temporary location for installation. In other
> words program is not supposed to work from there, but should work after
> all files moved from DESTDIR to /. Now during make install ebtables
> generate scripts, and substitute some PATHs there, so that in result
> scripts are supposed to work from destdir and do not work from /, which
> is wrong. Attached patch fixes the issue. It uses DESTDIR only on for
> directories we are going to install files into. Please, review and
> commit. Thank you.

Applied to CVS, thanks. Changed PIPE_DIR too, for completeness.

Bart

Re: [Ebtables-devel] [patch] TEXT relocation and related compilation problem on amd64.

[Bart De S. <bds...@pa...>]

Op zo, 12-08-2007 te 14:15 +0400, schreef Peter Volkov:
> Hello.
> 
> It was reported that ebtables-2.8.0.1 does not compiles on amd64 (see
> comment #10 of http://bugs.gentoo.org/show_bug.cgi?id=159371 ). The fix
> is simple and is in applied patch. This fix besides that also fixes text
> relocations which is in lib/ebtables/libebtc.so. Could anybody review
> and apply it in CVS? Thank you.

Thanks, a similar patch is already in CVS, see:
http://ebtables.cvs.sourceforge.net/ebtables/ebtables2/userspace/ebtables2/Makefile?r1=1.54&r2=1.55

I also put the $(CFLAGS_SH_LIB) for the ebtables-standalone.o target, I
suppose that's no problem, right?

cheers,
Bart

[Ebtables-devel] [patch] DESTDIR does not handeled properly.

[Peter V. <pv...@ge...>]

Hello.

ebtables build system (Makefile :) ) currently does not handle DESTDIR
correctly. DESTDIR is the temporary location for installation. In other
words program is not supposed to work from there, but should work after
all files moved from DESTDIR to /. Now during make install ebtables
generate scripts, and substitute some PATHs there, so that in result
scripts are supposed to work from destdir and do not work from /, which
is wrong. Attached patch fixes the issue. It uses DESTDIR only on for
directories we are going to install files into. Please, review and
commit. Thank you.

-- 
Peter.

[Ebtables-devel] [patch] TEXT relocation and related compilation problem on amd64.

[Peter V. <pv...@ge...>]

Hello.

It was reported that ebtables-2.8.0.1 does not compiles on amd64 (see
comment #10 of http://bugs.gentoo.org/show_bug.cgi?id=159371 ). The fix
is simple and is in applied patch. This fix besides that also fixes text
relocations which is in lib/ebtables/libebtc.so. Could anybody review
and apply it in CVS? Thank you.

-- 
Peter.

Re: [Ebtables-devel] sopport for multicasting

[Bart De S. <bds...@pa...>]

Op do, 28-06-2007 te 13:57 +0400, schreef Crazy AMD K7:
> Hello all.
> I would like to ask what I should do to make my bridge to support
> multicasting?
> If I am connecting my computer before the bridge everything works ok.
> Behind the bridge everything is ok, but multicasting packets do not pass.
> 
> I am using 2.4.35-pre5 kernel + ebtables-brnf-11-2_vs_2.4.31.diff
> iptables -I FORWARD -j ACCEPT
> sysctl: net.ipv4.conf.bridge0.force_igmp_version = 2
> ( echo 2>/proc/sys/net/ipv4/conf/bridge0/force_igmp_version )
> .config
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_MROUTE=y
> CONFIG_IP_PIMSM_V1=y
> CONFIG_IP_PIMSM_V2=y
> CONFIG_BRIDGE=y
> # CONFIG_BRIDGE_NF_EBTABLES is not set
> 
> What else I should do on the bridge?

Are you using iptables rules that could be the cause of these problems?
Does it work without the bridge patch?

cheers,
Bart

[Ebtables-devel] sopport for multicasting

[Crazy A. K7 <100...@ma...>]

Hello all.
I would like to ask what I should do to make my bridge to support
multicasting?
If I am connecting my computer before the bridge everything works ok.
Behind the bridge everything is ok, but multicasting packets do not pass.

I am using 2.4.35-pre5 kernel + ebtables-brnf-11-2_vs_2.4.31.diff
iptables -I FORWARD -j ACCEPT
sysctl: net.ipv4.conf.bridge0.force_igmp_version = 2
( echo 2>/proc/sys/net/ipv4/conf/bridge0/force_igmp_version )
.config
CONFIG_IP_MULTICAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_BRIDGE=y
# CONFIG_BRIDGE_NF_EBTABLES is not set

What else I should do on the bridge?

Pavel

[Ebtables-devel] WDS switching

[Ivan M. <muc...@gm...>]

I, i'm an italian student.
I'm doing some research in wireless mesh network for my thesis.
I have developed an user space layer-2 routing protcol like hwmp protocol,
in 802.11s standard.
I'm doing some semplification in my implmetation. I'm working with
madwifi-ng driver.
I had my "forwarding" table in user space and I need to porting it somewhere
in the linux bridge...
I create a WDS interface (VAP) for every neighbour I discover and I put the
virtual interfaces in a bridge, with spanning tree disabled.

I nedd to bridge the input frames to a specific output interface of the
bridge based on destination address. So I need the bridge work as a
controlled switch, not as a bridge.

Do you have a suggestion about what "tool" I can use? Do you think I can do
that with ebtables? Or I nedd to add some ioctl in linux bridge code?

[Ebtables-devel] br_forward_finish & br_nf_local_out_finish in 2.4.x vs. 2.6.x

[Fei <njp...@gm...>]

Hi,

I have a question:

In linux-2.4.21/net/bridge/br_netfilter.c::br_nf_local_out()
-------------------------------------------------------------------------------
734     /* IP forwarded traffic has a physindev, locally
735      * generated traffic hasn't.
736      */
737     if (realindev != NULL) {
738         if (((nf_bridge->mask & BRNF_DONT_TAKE_PARENT) == 0) &&
739             has_bridge_parent(realindev))
740             realindev = bridge_parent(realindev);
741         NF_HOOK_THRESH(pf, NF_IP_FORWARD, skb, realindev,
742                    realoutdev, okfn,
743                    NF_IP_PRI_BRIDGE_SABOTAGE_FORWARD + 1);
744     } else {
745 #ifdef CONFIG_NETFILTER_DEBUG
746         skb->nf_debug ^= (1 << NF_IP_LOCAL_OUT);
747 #endif
748
749         NF_HOOK_THRESH(pf, NF_IP_LOCAL_OUT, skb, realindev,
750                    realoutdev, okfn,
751                    NF_IP_PRI_BRIDGE_SABOTAGE_LOCAL_OUT + 1);
752     }
-------------------------------------------------------------------------------

In above code snippets, okfn points to
net/bridge/br_forward.c::br_forward_finish(), which means the IP
packets locally generated will NOT pass through the ebtables OUTPUT
chain in filter table, right?

However, in linux-2.6.11 kernel, okfn points to
net/bridge/br_netfilter.c::br_nf_local_out_finish(), which means  the
IP packets locally generated will pass through the ebtables OUTPUT
chain in filter table, right?

Why is there different behavior between 2.4.x and 2.6.11?

Thanks,
Fei

[Ebtables-devel] Queue to Userspace development

[Jim B. <jb...@de...>]

I was wondering if anyone has done an equivalent queue to Userspace support
for ebtables like iptables (I see it liseted as an open item)?

Any leads/pointers would be great.

/Jim

Re: [Ebtables-devel] [PATCH] add gratuitous arp filtering

[Patrick M. <ka...@tr...>]

Bart De Schuymer wrote:
> The attached patch adds gratuitous arp filtering, more precisely: it
> allows checking that the IPv4 source address matches the IPv4
> destination address inside the ARP header. It also adds a check for the
> hardware address type when matching MAC addresses (nothing critical,
> just for better consistency).


Applied, thanks Bart.

Re: [Ebtables-devel] [PATCH] add gratuitous arp filtering

[Carl-Daniel H. <c-d...@gm...>]

On 25.03.2007 20:21, Bart De Schuymer wrote:
> Hi Patrick,
> 
> The attached patch adds gratuitous arp filtering, more precisely: it
> allows checking that the IPv4 source address matches the IPv4
> destination address inside the ARP header. It also adds a check for the
> hardware address type when matching MAC addresses (nothing critical,
> just for better consistency).
> 
> Signed-off-by: Bart De Schuymer <bds...@pa...>

Looks good to me, but not yet tested.

Acked-by: Carl-Daniel Hailfinger <c-d...@gm...>

Regards,
Carl-Daniel

[Ebtables-devel] [PATCH] add gratuitous arp filtering

[Bart De S. <bds...@pa...>]

Hi Patrick,

The attached patch adds gratuitous arp filtering, more precisely: it
allows checking that the IPv4 source address matches the IPv4
destination address inside the ARP header. It also adds a check for the
hardware address type when matching MAC addresses (nothing critical,
just for better consistency).

cheers,
Bart

Signed-off-by: Bart De Schuymer <bds...@pa...>

Re: [Ebtables-devel] filter bridged IPv4/IPv6 encapsulated in pppoe traffic

[Patrick M. <ka...@tr...>]

Bart De Schuymer wrote:
> See attachment. The rediff is on my account. Fixed a compile error when
> CONFIG_SYSCTL isn't defined and updated the Documentation. Use
> vlan_eth_hdr and skb->network_header.


Applied, thanks Bart.

Re: [Ebtables-devel] filter bridged IPv4/IPv6 encapsulated in pppoe traffic

[Bart De S. <bds...@pa...>]

Op do, 22-03-2007 te 23:07 +0100, schreef Patrick McHardy:
> Bart De Schuymer wrote:
> > Hi Patrick,
> > 
> > The attached patch by Michael Milner adds support for using iptables and
> > ip6tables on bridged traffic encapsulated in ppoe frames, similar to
> > what's already supported for vlan.
> 
> 
> Looks good, but doesn't apply to the net-2.6.22 tree since
> it conflicts with Arnaldo's skb accessor changes. Please
> rediff and resend.

See attachment. The rediff is on my account. Fixed a compile error when
CONFIG_SYSCTL isn't defined and updated the Documentation. Use
vlan_eth_hdr and skb->network_header.

Signed-off-by: Michael Milner <mi...@bl...>
Signed-off-by: Bart De Schuymer <bds...@pa...>

cheers,
Bart

Re: [Ebtables-devel] [PATCH] don't answer gratuitous arp

[Bart De S. <bds...@pa...>]

Op vr, 23-03-2007 te 09:36 +0200, schreef Ivan Vladimirov:
> Carl-Daniel Hailfinger wrote:
> > On 22.03.2007 21:36, Bart De Schuymer wrote:
> >   
> >> Hi Patrick,
> >>
> >> The ebtables arpreply target should not answer gratuitous arp's as this
> >> has no use and can give rise to problems when client machines
> >> send gratuitous arp requests to check for ip conflicts, as reported by
> >> Ivan Vladimirov.
> >> The attached patch resolves this.
> >>     
> >
> > Please don't apply this patch! It causes more problems than it solves.
> > Before the patch, a client machine has a chance to find out that its
> > IP conflicts with one handled by the arpreply target. After the patch,
> > there will still be an IP conflict, but it is now impossible to find
> > that out for the affected machine.
> >
> > Regards,
> > Carl-Daniel
> >   
> You are wrong about ip conflict with machine  having arpreply on it . In
> case when client machine conflicts with server having arpreply target
> arpreply wont answer  but the network stack while answer so your consern
> is pointless ...

Can you explain yourself further, I tend to agree with Carl-Daniel's
comment. Are you sure there is no configuration that will suffer from
applying this patch?
I'll add the --arp-gratuitous option to the ebtables arp match this
weekend. That way we don't break anything and checking on gratuitous arp
packets can be done elsewhere too.

cheers,
Bart