Date: Wed, 15 Feb 2012 22:28:31 GMT From: Freek Dijkstra <public@macfreek.nl> To: freebsd-gnats-submit@FreeBSD.org Subject: i386/165190: [ipfw] loopback interface is not marking ipv6 packets Message-ID: <201202152228.q1FMSVVO075885@red.freebsd.org> Resent-Message-ID: <201202152230.q1FMUAMA092073@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 165190 >Category: i386 >Synopsis: [ipfw] loopback interface is not marking ipv6 packets >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 15 22:30:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Freek Dijkstra >Release: 9.0-RELEASE >Organization: >Environment: FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: ipfw matches and reports the incorrect interface for IPv6 traffic via the loopback interface. E.g. > 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 (the in via em0 should be in via lo0). >How-To-Repeat: 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=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 em0: flags=8843<UP,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. It also indicates that em0 is not used: if both lo0 and em0 would be used, the smaller MTU of em0 would block larger packets, and this is not the case. Hence, em0 seems not used all, despite the reporting of ipfw. >Fix: Suggested by Julian Elischer: lo0 is not marking ipv6 packets. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202152228.q1FMSVVO075885>