From owner-freebsd-net Tue May 30 18: 6:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id BDFAD37BDCC for ; Tue, 30 May 2000 18:06:15 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA04816; Wed, 31 May 2000 10:06:11 +0900 (JST) To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG In-reply-to: archie's message of Tue, 30 May 2000 14:55:26 MST. <200005302155.OAA00803@bubba.whistle.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: BPF fix to if_loop.c From: itojun@iijlab.net Date: Wed, 31 May 2000 10:06:11 +0900 Message-ID: <4814.959735171@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> sorry this was incorrect. however, I think there should be check >> if ifp really wants DLT_NULL encapsulation or not. >Hmm.. maybe a better fix is to remove this BPF section altogether.. ? >It's only going to result in showing the same packet twice, right? there are couple of different stories here. note that you can pass any ifp to if_simloop(). a. when if_simloop(ifp = lo0), there must be call to bpf_mtap, with DLT_NULL encapsulation. if we don't do it here, nobody will. b. when if_simloop(ifp = non-lo0), there are two cases. b1. if it was called from layer 2 specific code like if_ethersubr.c, if_simloop may want to inject the packet with no encapsulation change. b2. if it was called from ip{6,}_mloopback, if_simloop() must not call bpf_mtap. with the current code, ifp_simloop injects packet as is (with no layer 2 header) into, for example to bpf for ethernet interface, passing junk to bpf listeners. this is the problem I experienced. in case of b1, your description should be correct (seeing same packet twice). in case of b2, I'm still not sure how to resolve it. maybe I don't get the ultimate goal for this change from 4.4BSD. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message