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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
