From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 18:39:31 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 19C9016A468; Mon, 14 Jan 2008 18:39:31 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by mx1.freebsd.org (Postfix) with SMTP id 3868913C4CE; Mon, 14 Jan 2008 18:39:29 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Mon, 14 Jan 2008 18:39:29 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id EFC88181421; Mon, 14 Jan 2008 18:39:28 +0000 (GMT) Message-ID: <478BAC60.9030506@tomjudge.com> Date: Mon, 14 Jan 2008 18:39:28 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> In-Reply-To: <478B982B.304@FreeBSD.org> 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:39:31 -0000 Bruce M. Simpson wrote: > Tom Judge wrote: >> Thanks for the response. I have a quick grep of the src tree to find >> an example of this being used and only found the following from >> wpa_supplicant and I have a few questions: >> >> * I am presuming that this will do what I want, am I correct? > > Yes, it will attempt to add the given link layer multicast group to the > ifnet's underlying device driver. >> >> * If I was only ever to add the address to an interface an never >> delete it would this cause any problems? I.e. when lldpd ends, or is >> restarted and tries to add the address again? > > SIOCADDMULTI is very low level, no resource tracking is performed; I > changed its semantics to only allow one userland opener so that > in-kernel refcounting would work, as there is no per-process or > per-client resource tracking -- so it's a really good idea to clean up > after it. > >> >> * Alternatively is there a way to query the filter to ask what >> addresses it is currently programmed for? > > Nope, there is no userland or kernel API for that unless you hack up the > driver. > 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? 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. On a side note does anyone know if if_bridge will respect the standard and not forward this frame on to other interfaces? Thanks again Tom