kern/112612: Traffic via additional lo(4) interface shows up on lo0 in bpf(4)

[Yar Tikhiy]

>Number:         112612
>Category:       kern
>Synopsis:       Traffic via additional lo(4) interface shows up on lo0 in bpf(4)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 12 12:30:15 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Yar Tikhiy
>Release:        FreeBSD 7.0-CURRENT i386
>Organization:
none
>Environment:
System: FreeBSD jujik.ramtel.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Apr 22 15:52:48 MSD 2007 root at jujik.ramtel.ru:/usr/src/sys/i386/compile/JTEST i386

>Description:
	tcpdump(1) on an additional loopback interface shows no
	traffic at all.  The traffic can be seen if tcpdump(1) runs
	on the primary loopback interface instead, which is usually
	lo0.

	I believe that the bug was introduced in rev. 1.111 of
	if_loop.c.  Due to that change, if_simloop() explicitly
	passes any loopback traffic to BPF on behalf of loif, i.e.,
	the primary loopback interface.

>How-To-Repeat:
	1. Create an additional lo(4) interface:
		ifconfig lo1 create
		ifconfig lo1 127.0.0.2
	2. Create ipfw rules to see that traffic actually goes via lo1:
		ipfw add 50 count icmp from any to any via lo0
		ipfw add 50 count icmp from any to any via lo1
	3. Start tcpdump on lo1:
		tcpdump -vpn -i lo1 icmp
	4. Ping via lo1:
		ping -c1 127.0.0.1
	5. See the counter increase on lo1, but no traffic in tcpdump.
	6. Repeat #3,4 running tcpdump on lo0 instead, see the missing
	   traffic showing up as though it flows via lo0.

>Fix:
	Not know yet, but a promising approach is to test IFF_LOOPBACK
	on the actual interface, ifp, and not override it with loif in
	the bpf_mtap2() call if the flag is set.
>Release-Note:
>Audit-Trail:
>Unformatted: