Date: Fri, 27 Apr 2001 12:27:09 -0700 From: Bill Fenner <fenner@research.att.com> To: net@freebsd.org Subject: if_simloop() and BPF Message-ID: <200104271927.MAA07009@windsor.research.att.com>
next in thread | raw e-mail | index | archive | help
BPF handling in if_simloop() is broken for every use except for from looutput(). Why? BPF write: BPF writes go through if_output, and if_simloop() is not an if_output routine. This code should be in looutput(). BPF tap: if_simloop() prepends the header that BPF expects when it's capturing on a DLT_NULL interface. This is only correct behavior when the interface being looped is a DLT_NULL interface type, which is pretty rare. In addition, it's often not appropriate to tap a copy of the packet that is going through if_simloop(), e.g. looping back a broadcast on a simplex link -- bpf is going to see the output copy as well. I summarized each caller to if_simloop() and its behavior at: http://people.freebsd.org/~fenner/if_simloop_callers.html . The No/No/No lines are obvious, they don't want the bpf_tap at all. The Yes/No/No lines point at problems that the current if_simloop() doesn't handle, and we need more infrastructure to deal with it. Right now, I'm tempted to move the BPF tap back to looutput() also, which fixes the cases where the if_simloop() caller sholdn't have the copy sent to bpf, and breaks all of the already-broken cases where if_simloop()'s caller wants the copy sent to bpf but that copy will almost definitely have the wrong header prepended. Another option is to add a few more arguments to if_simloop(), indicating things like tap or don't, and what the BPF header should look like if you tap. Note that netatalk/ddp_output.c would have trouble coming up with that, unless it was simply a property of the interface. Any comments? Thanks, Bill P.S. Historically, callers to looutput() got their packets bpf'd on the loopback interface. Thus they would show up on the wrong and somewhat unexpected interface, but their BPF headers would be right. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104271927.MAA07009>