Re: Local IPv6 traffic not send over loopback?
Hi Julian and Terrence, Thanks for your tests! I'm now convinced there is a bug in ipfw. As Terrence and I tested, ipfw is matching rules, and reporting in the log, that IPv6 traffic between local IPv6 addresses (from me6 to me6) using an interface other than lo0. e.g. ipfw: 1 Count ICMPv6:128.0 [2001:610:767:1981::1] [2001:610:767:1981::1] in via em3 This was in contrast with route get, which reported that the traffic would use lo0. So either route or ipfw is wrong. By varying the MTU size, I verified that ping6 traffic from two local IPv6 addresses (not ::1) indeed uses the lo0 (loopback) interface. Thus not the em3 interface as ipfw is reporting. I can only conclude that this is a bug in ipfw. Is there a place where I can submit a bug report? While writing down the bug report, I realised that in my previous mail there were actually two issues: 1. ipfw reports that IPv6 traffic from me to me is using a non-loopback interface. This is unexpected to me, since the traffic really seems to use the loopback interface lo0, as reported by route get and tested by varying the MTU. 2. ICMPv6 replies originating at the pinged host match a rule with the recv pattern. This is unexpected to me, given the line man 8 ipfw: packets originating from the local host have no receive interface To separate the two issues, I've included two bug reports below. Regards, Freek _ __ Report #1: ipfw reports wrong interface for IPv6 loopback traffic Summary: ipfw matches and reports incorrect interface for IPv6 traffic between through the lookback interface in case the source/destination IP is not ::1. Steps to reproduce: 1. Determine a global IPv6 address of your host. In this report, 2001:610:767:4ec1::1 is used. 2. Verify that the routing table has an entry associating this IP address with the loopback interface. E.g.: % route get -inet6 2001:610:767:4ec1::1 route to: 2001:610:767:4ec1::1 destination: 2001:610:767:4ec1::1 interface: lo0 3. Add the following rules to ipfw: # ipfw add 1 count log ipv6 from me6 to me6 recv lo0 # ipfw add 2 count log ipv6 from me6 to me6 not recv lo0 4. Run sudo sysctl net.inet.ip.fw.one_pass=0 5. Ping the local IP: % ping6 -c 1 2001:610:767:4ec1::1 6. examine the IPFW log file. Expected result: I expected rule 1 to match: ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 Actual result: Rule 2 matched: ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 Further analysis: Adding rules for xmit lo0 and not xmit lo0 clearly show that according to ipfw, the packet is xmit lo0 recv em0. Beside using route get in step 2 above, there is another method to determine the interface that is used by the packet, the MTU size. By default, the MTU of lo0 is 16384 bytes, and other interface have a MTU of 1500 bytes: % ifconfig: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 % ping6 -c 1 -D -s 16336 -b 32000 2001:610:767:4ec1::1 works fine % ping6 -c 1 -D -s 16337 -b 32000 2001:610:767:4ec1::1 fails Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes, so that indicates the actual interface used is lo0, not em0. Since a packet of 16384 bytes comes through, and em0 has a MTU of 1500 bytes, this also means that em0 is really not used, and the receiving interface as reported and matched by ipfw is wrong. _ __ Report #2: ipfw matches recv data for outgoing ICMPv6 replies. Summary: When a host creates an IPv6 reply packets and sends it out, the packet is matched by a ipfw rule with a recv pattern. Steps to reproduce: 1. Determine the IPv6 addresses of two hosts, and make sure they can ping each other over IPv6. 2. On one host, add the following rules to ipfw: # ipfw add 10 count log icmp6 from any to me # ipfw add 11 count log icmp6 from any to me recv \* # ipfw add 12 count log icmp6 from any to me xmit \* # ipfw add 13 count log icmp6 from any to me in recv \* # ipfw add 14 count log icmp6 from any to me out recv \* # ipfw add 15 count log icmp6 from any to me out xmit \* # ipfw add 20 count log icmp6 from me to any # ipfw add 21 count log icmp6 from me to any recv \* # ipfw add 22 count log icmp6 from me to any xmit \* # ipfw add 23 count log icmp6 from me to any in recv \* # ipfw add 24 count log icmp6 from me
Re: Local IPv6 traffic not send over loopback?
On 2/15/12 1:44 PM, Freek Dijkstra wrote: Hi Julian and Terrence, Thanks for your tests! I'm now convinced there is a bug in ipfw. As Terrence and I tested, ipfw is matching rules, and reporting in the log, that IPv6 traffic between local IPv6 addresses (from me6 to me6) using an interface other than lo0. e.g. ipfw: 1 Count ICMPv6:128.0 [2001:610:767:1981::1] [2001:610:767:1981::1] in via em3 This was in contrast with route get, which reported that the traffic would use lo0. So either route or ipfw is wrong. By varying the MTU size, I verified that ping6 traffic from two local IPv6 addresses (not ::1) indeed uses the lo0 (loopback) interface. Thus not the em3 interface as ipfw is reporting. I can only conclude that this is a bug in ipfw. Is there a place where I can submit a bug report? While writing down the bug report, I realised that in my previous mail there were actually two issues: 1. ipfw reports that IPv6 traffic from me to me is using a non-loopback interface. This is unexpected to me, since the traffic really seems to use the loopback interface lo0, as reported by route get and tested by varying the MTU. 2. ICMPv6 replies originating at the pinged host match a rule with the recv pattern. This is unexpected to me, given the line man 8 ipfw: packets originating from the local host have no receive interface To separate the two issues, I've included two bug reports below. Regards, Freek _ __ Report #1: ipfw reports wrong interface for IPv6 loopback traffic Summary: ipfw matches and reports incorrect interface for IPv6 traffic between through the lookback interface in case the source/destination IP is not ::1. Steps to reproduce: 1. Determine a global IPv6 address of your host. In this report, 2001:610:767:4ec1::1 is used. 2. Verify that the routing table has an entry associating this IP address with the loopback interface. E.g.: % route get -inet6 2001:610:767:4ec1::1 route to: 2001:610:767:4ec1::1 destination: 2001:610:767:4ec1::1 interface: lo0 3. Add the following rules to ipfw: # ipfw add 1 count log ipv6 from me6 to me6 recv lo0 # ipfw add 2 count log ipv6 from me6 to me6 not recv lo0 4. Run sudo sysctl net.inet.ip.fw.one_pass=0 5. Ping the local IP: % ping6 -c 1 2001:610:767:4ec1::1 6. examine the IPFW log file. Expected result: I expected rule 1 to match: ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 Actual result: Rule 2 matched: ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 there is the bug: lo0 is not marking ipv6 packets. ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 Further analysis: Adding rules for xmit lo0 and not xmit lo0 clearly show that according to ipfw, the packet is xmit lo0 recv em0. Beside using route get in step 2 above, there is another method to determine the interface that is used by the packet, the MTU size. By default, the MTU of lo0 is 16384 bytes, and other interface have a MTU of 1500 bytes: % ifconfig: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 % ping6 -c 1 -D -s 16336 -b 32000 2001:610:767:4ec1::1 works fine % ping6 -c 1 -D -s 16337 -b 32000 2001:610:767:4ec1::1 fails Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes, so that indicates the actual interface used is lo0, not em0. Since a packet of 16384 bytes comes through, and em0 has a MTU of 1500 bytes, this also means that em0 is really not used, and the receiving interface as reported and matched by ipfw is wrong. _ __ Report #2: ipfw matches recv data for outgoing ICMPv6 replies. Summary: When a host creates an IPv6 reply packets and sends it out, the packet is matched by a ipfw rule with a recv pattern. Steps to reproduce: 1. Determine the IPv6 addresses of two hosts, and make sure they can ping each other over IPv6. 2. On one host, add the following rules to ipfw: # ipfw add 10 count log icmp6 from any to me # ipfw add 11 count log icmp6 from any to me recv \* # ipfw add 12 count log icmp6 from any to me xmit \* # ipfw add 13 count log icmp6 from any to me in recv \* # ipfw add 14 count log icmp6 from any to me out recv \* # ipfw add 15 count log icmp6 from any to me out xmit \* # ipfw add 20 count log icmp6 from me to any # ipfw add 21 count log icmp6 from me to any recv \* # ipfw add 22 count log icmp6 from me to any xmit \* #
Re: Local IPv6 traffic not send over loopback?
Julian Elischer wrote: can you actually put them in an official bug report? Done for the first report. I'll follow up once it is approved. Do you have any comments about the second problem? (unlike the first, that only seem to occur with ICMPv6 traffic). The bug report page was new; I was surprised not to see a reference to the problem reassemlbing fragemented IPv6 traffic, are reported last year: http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-October/004918.html Am I overlooking something, or should I try to examine a bit further and file a bug report for that as well? Regards, Freek _ __ Report #1: ipfw reports wrong interface for IPv6 loopback traffic Summary: ipfw matches and reports incorrect interface for IPv6 traffic between through the lookback interface in case the source/destination IP is not ::1. Steps to reproduce: 1. Determine a global IPv6 address of your host. In this report, 2001:610:767:4ec1::1 is used. 2. Verify that the routing table has an entry associating this IP address with the loopback interface. E.g.: % route get -inet6 2001:610:767:4ec1::1 route to: 2001:610:767:4ec1::1 destination: 2001:610:767:4ec1::1 interface: lo0 3. Add the following rules to ipfw: # ipfw add 1 count log ipv6 from me6 to me6 recv lo0 # ipfw add 2 count log ipv6 from me6 to me6 not recv lo0 4. Run sudo sysctl net.inet.ip.fw.one_pass=0 5. Ping the local IP: % ping6 -c 1 2001:610:767:4ec1::1 6. examine the IPFW log file. Expected result: I expected rule 1 to match: ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 Actual result: Rule 2 matched: ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 there is the bug: lo0 is not marking ipv6 packets. ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 Further analysis: Adding rules for xmit lo0 and not xmit lo0 clearly show that according to ipfw, the packet is xmit lo0 recv em0. Beside using route get in step 2 above, there is another method to determine the interface that is used by the packet, the MTU size. By default, the MTU of lo0 is 16384 bytes, and other interface have a MTU of 1500 bytes: % ifconfig: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 % ping6 -c 1 -D -s 16336 -b 32000 2001:610:767:4ec1::1 works fine % ping6 -c 1 -D -s 16337 -b 32000 2001:610:767:4ec1::1 fails Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes, so that indicates the actual interface used is lo0, not em0. Since a packet of 16384 bytes comes through, and em0 has a MTU of 1500 bytes, this also means that em0 is really not used, and the receiving interface as reported and matched by ipfw is wrong. _ __ Report #2: ipfw matches recv data for outgoing ICMPv6 replies. Summary: When a host creates an IPv6 reply packets and sends it out, the packet is matched by a ipfw rule with a recv pattern. Steps to reproduce: 1. Determine the IPv6 addresses of two hosts, and make sure they can ping each other over IPv6. 2. On one host, add the following rules to ipfw: # ipfw add 10 count log icmp6 from any to me # ipfw add 11 count log icmp6 from any to me recv \* # ipfw add 12 count log icmp6 from any to me xmit \* # ipfw add 13 count log icmp6 from any to me in recv \* # ipfw add 14 count log icmp6 from any to me out recv \* # ipfw add 15 count log icmp6 from any to me out xmit \* # ipfw add 20 count log icmp6 from me to any # ipfw add 21 count log icmp6 from me to any recv \* # ipfw add 22 count log icmp6 from me to any xmit \* # ipfw add 23 count log icmp6 from me to any in recv \* # ipfw add 24 count log icmp6 from me to any out recv \* # ipfw add 25 count log icmp6 from me to any out xmit \* 3. From the other host, ping the first host (with the ipfw rules), e.g.: % ping6 -c 1 2001:610:767:4ec1::1 4. examine the IPFW log file. Expected result: ipfw: 10 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 ipfw: 11 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 ipfw: 13 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 ipfw: 20 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 ipfw: 22 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out
Re: Local IPv6 traffic not send over loopback?
Freek Dijkstra wrote: can you actually put them in an official bug report? Done for the first report. I'll follow up once it is approved. http://www.freebsd.org/cgi/query-pr.cgi?pr=165190 (It seems I mis-categorised it: I marked it i386, since that was the platform I used for testing; it should probably be categorised in kern). Freek ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
