ebtables-restore 2.0.10-4 IPv6 rule loading bug

[Luis Fernando <tdthp@terra.com.br>]

Hello

I believe I found a bug in ebtables-restore.
I have the following set of rules (saved with ebtables-save):
# Generated by ebtables-save v1.0 on Tue Jun 25 16:15:00 BRT 2013
*filter
:INPUT ACCEPT
:FORWARD DROP
:OUTPUT ACCEPT
:INPUT-VLAN29 DROP
:OUTPUT-VLAN29 DROP
:OUTPUT-VLAN33 DROP
:OUTPUT-VLAN34 DROP
:OUTPUT-VLAN35 DROP
-A FORWARD -p IPv4 --ip-proto udp --ip-sport 67:68 --log-level info --log-prefix "dhcp_spoofing_denied" --log-ip -j DROP
-A FORWARD -p IPv6 --ip6-proto udp --ip6-sport 547 --log-level info --log-prefix "dhcp6_spoofing_denied" --log-ip -j DROP
-A FORWARD -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement --log-level info --log-prefix "ra6_spoofing_denied" -j DROP
-A FORWARD -i eth1.29 -j INPUT-VLAN29
-A FORWARD -o eth1.29 -j OUTPUT-VLAN29
-A FORWARD -o eth2 -j ACCEPT
-A INPUT-VLAN29 -p IPv6 -s 0:50:56:0:0:15 -i eth1.29 --ip6-src ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff -j RETURN
-A INPUT-VLAN29 -p IPv4 -s 0:50:56:0:0:15 -i eth1.29 --ip-src 10.133.145.120 -j RETURN
-A OUTPUT-VLAN29 -p IPv6 -d 0:50:56:0:0:15 -o eth1.29 --ip6-dst ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff -j ACCEPT
-A OUTPUT-VLAN29 -p IPv4 -d 0:50:56:0:0:15 -o eth1.29 --ip-dst 10.133.145.120 -j ACCEPT 

When I load them manually (after flushing/deleting/creating the chains), they work. If I ebtables-restore them and then run the following commands, they also work:
ebtables -D INPUT-VLAN29 -p IPv6 -s 0:50:56:0:0:15 -i eth1.29 --ip6-src ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff -j RETURN
ebtables -I INPUT-VLAN29 -p IPv6 -s 0:50:56:0:0:15 -i eth1.29 --ip6-src ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff -j RETURN

I noticed, though, that when I just use ebtables-restore, this rule was not being matched. After comparing a lot of --atomic-save dumps (working vs not-working), and reading a bit about ebtables structs, I found out that when I use restore, this is what is stored in the kernel (I'll color it to try to make it look easier for you):
http://i.imgur.com/E4t6f2o.png

When I run the commands manually, this is the result:
http://i.imgur.com/IJgqwKB.png

The colors (accordingly to ebt_ip6_info @ include/linux/netfilter_bridge/ebt_ip6.h ) represents:

BLUE -> source IPv6 address
RED -> dest IPv6 address
CYAN -> source IPv6 mask
ORANGE -> dest IPv6 mask

As you can see (bold), however, in the restored version there's trash in the source IPv6 address and mask. I'd put my money on a zeroing problem, but I couldn't find it so far.

There's a workaround for this issue, which is specifying an ip6-dst with mask 0:
removing -A INPUT-VLAN29 -p IPv6 -s 0:50:56:0:0:15 -i eth1.29 --ip6-src ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff -j RETURN
adding -A INPUT-VLAN29 -p IPv6 -s 0:50:56:0:0:15 -i eth1.29 --ip6-src ::250:56ff:fe00:15/::ffff:ffff:ffff:ffff --ip6-dst ::/:: -j RETURN

This probably forces the initialization of the dest ipv6 fields to zero.
Another interesting fact is that if the INPUT-VLAN29 IPv4 rule is commented out, this problem doesn't happen (maybe indicating that this rule is invading the memory of the IPv6 one).
I also noticed that if you comment most of the rules in this file, it will work correctly (that's why I had kept the OUTPUT-VLAN33/34/35 for instance).
So maybe it's related to the chain creation/replacing.

Any ideas on promising debugging I could do?

thanks,
-- Luís Fernando

--
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