From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 18:48:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B525216A46B for ; Mon, 14 Jan 2008 18:48:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 759C813C4E3 for ; Mon, 14 Jan 2008 18:48:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 68F08891C5; Mon, 14 Jan 2008 13:48:18 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Jan 2008 13:48:18 -0500 X-Sasl-enc: 2W9NKTyf7cVOWJKhzBzl3vEPRcfHplybr7HgbhIKWEct 1200336498 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E53AC2A0B6; Mon, 14 Jan 2008 13:48:17 -0500 (EST) Message-ID: <478BAE70.9050702@FreeBSD.org> Date: Mon, 14 Jan 2008 18:48:16 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Tom Judge References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> <478BAC60.9030506@tomjudge.com> In-Reply-To: <478BAC60.9030506@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 18:48:19 -0000 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