bugzilla-daemon at bugzilla.netfilter.org
2011-Nov-16 08:47 UTC
[Bug 761] New: Bug in ICMPv6 type and code fields processing
http://bugzilla.netfilter.org/show_bug.cgi?id=761 Summary: Bug in ICMPv6 type and code fields processing Product: ipset Version: unspecified Platform: i386 OS/Version: Gentoo Status: NEW Severity: major Priority: P5 Component: default AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy: sabitov at sabitov.su Estimated Hours: 0.0 yam ~ # uname -a Linux yam 3.0.6-gentoo #1 SMP PREEMPT Fri Oct 28 10:15:37 NOVT 2011 i686 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux yam ~ # ipset -V ipset v6.9.1, protocol version: 6 I'm not sure is it a bug in ipset util or in kernel module, but something swaps type and code fields for several ICMPv6 types. I.e. in my fw settings I have: ICMPV6_TYPES=( 128/0 # Echo Request 129/0 # Echo Reply 133/0 # Router Solicitation (NDP) 134/0 # Router Advertisement (NDP) 135/0 # Neighbor Solicitation (NDP) 136/0 # Neighbor Advertisement (NDP) ) ICMPV6_LEGAL_DEST=( ::1 # Localhost 2000::/3 # Global Unicast addrs fe80::/10 # Link-local Unicast addrs ff00::/8 # Multicast addrs ) ipset -! destroy legal_icmpv6_list ipset -! create legal_icmpv6_list hash:net,port family inet6 ipset flush legal_icmpv6_list for dest in ${ICMPV6_LEGAL_DEST[@]} ; do for icmp in ${ICMPV6_TYPES[@]} ; do ipset add -! legal_icmpv6_list ${dest},icmpv6:${icmp} done done ip6tables -N input_icmpv6_packets ip6tables -A input_icmpv6_packets -m set --match-set "legal_icmpv6_list" dst,dst -j ACCEPT ip6tables -A input_icmpv6_packets -j LOG --log-prefix "ICMPv6 pkt: " ip6tables -A input_icmpv6_packets -j DROP ip6tables -A INPUT -p ICMPv6 -g input_icmpv6_packets After that, I got such lines in my log: Nov 16 14:57:42 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=33:33:ff:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=ff02:0000:0000:0000:0000:0001:fff9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 Nov 16 14:57:43 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0 Nov 16 14:57:43 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0 Nov 16 14:57:44 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0 Nov 16 14:57:47 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 Nov 16 14:57:48 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 Nov 16 14:57:49 yam kernel: ICMPv6 pkt: IN=eth1 OUTMAC=00:22:15:f9:89:a2:00:e0:4c:9f:0a:24:86:dd SRC=fe80:0000:0000:0000:1de5:d64e:a530:2977 DST=fe80:0000:0000:0000:0222:15ff:fef9:89a2 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 Nov 16 14:57:49 yam kernel: ICMPv6 pkt: IN=eth1 OUT= MACSRC=fe80:0000:0000:0000:0222:15ff:fef9:89a2 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=96 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=134 CODE=0 Let's check the "legal_icmpv6_list" list: yam firewall # ipset test legal_icmpv6_list ff02:0000:0000:0000:0000:0000:0000:0001,icmpv6:134/0 ff02::1,ipv6-icmp:0/134 is in set legal_icmpv6_list. BUT MORE FUNNY!: yam firewall # ipset test legal_icmpv6_list ff02:0000:0000:0000:0000:0000:0000:0001,icmpv6:0/134 ff02::1,ipv6-icmp:router-advertisement is NOT in set legal_icmpv6_list. --------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If I add a 'swapped' types to my ICMPV6_TYPES list (0/134, 0/135 and so on), it works fine! -- Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are watching all bug changes.
bugzilla-daemon at bugzilla.netfilter.org
2011-Nov-25 08:40 UTC
[Bug 761] Bug in ICMPv6 type and code fields processing
http://bugzilla.netfilter.org/show_bug.cgi?id=761 Jozsef Kadlecsik <kadlec at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kadlec at netfilter.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jozsef Kadlecsik <kadlec at netfilter.org> 2011-11-25 09:40:07 --- This is a parser bug in ipset: the type and code are swapped. It's fixed in ipset 6.10, which I'm just releasing. -- Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are watching all bug changes.
Maybe Matching Threads
- Samba and ufw (mmcg29440@frontier.com)
- [Bug 742] New: ip6tables "-m iprange" ipv6 range detection
- GeForce 6100 (NV4E) & nouveau regression in 3.12
- [Bug 448] New: IPv6 conntrack does not work on a tunnel interface
- [Bug 576] New: ip6tables maks auto configuration packages as INVALID