multicast packets from bpf
Christian S.J. Peron
csjp at FreeBSD.org
Tue Aug 28 07:39:45 PDT 2007
On Tue, Aug 28, 2007 at 08:08:35AM +0100, Bruce M. Simpson wrote:
[..]
>
> I favour the first approach, however, it may make more sense to put the
> logic into bpf_movein() as it already builds a sockaddr based on the header
> data provided to bpf during a write.
>
> For the first patch: I previously fixed tapwrite() to check injected frames
> in the same way, as this was causing a problem with my own use of
> if_bridge. There is no way that I see for bpf to be able to tell if a frame
> is link-layer multicast or not, and checking at that layer does introduce a
> little pollution. Ethernet is the most common case so it could be argued
> that's OK, as we have ethernet-specific fields in struct mbuf now. Your
> change is the parallel change in the bpfwrite path to what I have in the
> tapwrite path.
>
I think that tap(4) is a bit different since the only kind of frames it
handles are Ethernet. This is not the case for bpf(4). I wonder if it
makes sense to add this check into ether_output()? IIRC bpf will call
the network interface's output routine, in the Ethernet/bridge case it
should be ether_output().
Thoughts?
--
Christian S.J. Peron
csjp at FreeBSD.ORG
FreeBSD Committer
More information about the freebsd-current
mailing list