Date: Mon, 14 Jan 2008 18:48:16 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Tom Judge <tom@tomjudge.com> Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. Message-ID: <478BAE70.9050702@FreeBSD.org> In-Reply-To: <478BAC60.9030506@tomjudge.com> References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> <478BAC60.9030506@tomjudge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tom Judge wrote: > > Ok, so if I can safely assume that the process sending/receiving the > LLDP frames should always be running would it be safe to use a helper > program to add the mac on system startup so it is always registered on > particular interfaces for the uptime of the system rather than having > the daemon add/remove the address on startup shutdown? > If not what problems would this create? If the daemon doesn't unregister its use of the link layer group, the kernel will not clean up after it. It won't prevent kernel entities from joining the group -- they will just acquire another reference -- but other userland clients will not be able to join the group until SIOCDELMULTI is called by at least one client. By the way, other processes can hijack this, but only if they have permission to use SIOCDELMULTI. I believe this requires root privileges. I believe it should be possible to use mtest to clean up manually. This is far from ideal and it really does want an API. NDIS, incidentally, can do all of what you describe. > > Personally I can't see why this approach would be a problem, but I am > not a expert. The address is defined in IEEE Std 802.1D-2004 as to > not be forwarded by bridges (which I interpret as it being link local > in a sense as switches/bridges are not allowed to forward the frame), > so I can't see it being a problem registered on multiple interfaces. SIOCADDMULTI memberships are specific to the interface you request them on. I can't speak for the bridging code -- I don't think it does any special handling of multicast frames, however I'm not sure if it's smart enough not to forward this group. Like IN_LOCALGROUP() it might need its own 'don't forward this' clause. later BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478BAE70.9050702>