From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 18:58:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79E21374; Mon, 28 Jan 2013 18:58:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6CE261; Mon, 28 Jan 2013 18:58:22 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B380BB997; Mon, 28 Jan 2013 13:58:21 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Testing SIOCADDMULTI? Date: Mon, 28 Jan 2013 11:09:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> In-Reply-To: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301281109.24879.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 13:58:21 -0500 (EST) Cc: Tim Kientzle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:58:22 -0000 On Sunday, January 27, 2013 1:51:12 am Tim Kientzle wrote: > > On Jan 26, 2013, at 3:56 PM, Tim Kientzle wrote: > > > My next TODO items for this network driver is to implement > > the SIOCADDMULTI and SIOCDELMULTI ioctls. > > Looking through other drivers (and net/if.c), I've > managed to implement ADDMULTI by adding > the multicast ethernet address to the list maintained > by the controller. > > DELMULTI seems trickier. Since if.c does not pass > the specific address being removed down to the > driver, it looks like I have no choice but to remove > every multicast address from the controller and then > re-insert all of the ones that are still valid. > > (This controller doesn't use a hash filter; it uses > a list of valid multicast addresses.) > > Is there a better approach? You should always reprogram the full table while holding if_maddr_rlock(). All the ioctl's tell you is that an entry was added or removed from that list. There is currently no race-free way for the stack to tell you which specific address to add or remove. > > I'm not quite sure what they do, though, and have > > no idea how to test them to see if they are working > > correctly. > > Would still appreciate any suggestions for how to test these. You can write a simple app to listen for UDP packets and have it join a multicast group and have another machine on the same network write a packet to the multicast group. However, a simpler test is to toggle the sysctl to enable multicast ping replies and to ping a multicast address from another machine after joining it on the test machine using mtest. -- John Baldwin