Date: Tue, 28 Aug 2007 08:08:35 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Andrew Thompson <thompsa@FreeBSD.org> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: multicast packets from bpf Message-ID: <46D3C9F3.2010802@FreeBSD.org> In-Reply-To: <20070828040026.GB42201@heff.fud.org.nz> References: <20070828040026.GB42201@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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). BTW this patch looks like it touches the paths which would need to be changed if IGMP snooping were to be implemented for if_bridge. regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D3C9F3.2010802>