multicast packets from bpf
Andrew Thompson
thompsa at FreeBSD.org
Tue Aug 28 03:31:13 PDT 2007
On Tue, Aug 28, 2007 at 08:08:35AM +0100, Bruce M. Simpson wrote:
> Seems reasonable, both patches are syntactically sane. There are
> arguments in favour of both changes.
>
> 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.
I had originally started to put it there but realised that I need a
pointer to the ifnet to read if_broadcastaddr, I didnt think it was
worth changing the function parameters when the check can also just go
in bpfwrite. I dont mind moving it if its the more correct place to put
it.
> 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.
Is the tapwrite patch still needed? The mbuf is passed to ether_input
which should do the right thing.
> The second patch: Conceptually similar to the loopback check in
> ip_output() for multicast. we wind up doing this check elsewhere, in
> particular netgraph. It is a relatively cheap check although it does
> involve changing the flags on a potentially read-only mbuf chain, which
> is bending the rules a bit (the stack often needs to change stuff in
> m_pkthdr even if the clusters are read-only).
I could go with this but it seems wrong to be passed a mbuf which has
incorrect flags, there may be other places in the stack that look for
M_*CAST that also have quirks.
Andrew
More information about the freebsd-current
mailing list