Date: Mon, 05 Feb 2007 21:30:33 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Jouke Witteveen <j.witteveen@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ioctl: SIOCADDMULTI (howto?) Message-ID: <45C7A1F9.20306@FreeBSD.org> In-Reply-To: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jouke Witteveen wrote: > Hello all, > > I'm in need of some information on how to utilize SIOCADDMULTI. It is > supposed to be demonstrated by the mtest [1] program, but that doesn't > do anything (on an SIOCDELMULTI rn it appears nothing was added: > ENOENT), At least not for the values I tested, 1.80.c2.0.0.1 in > particular. I presume it doesn't work because the program has not been > revised in 3 years and revision 1.4 notes that it might not work. > If this ioctl is depricated then please tell me what is the best way > to receive multicast messages from the 01.80.c2.00.00.0x (802.1) > range? It is ofcourse possible to go into ALLMULTI-mode and check on > all datagrams, but the NIC's I use are suited with a very nice > hardware filter (21143 chip) that should be able to do this more > effectively. Anyway, I believe Linux still programs the hardware > filter through SIOCADDMULTI so is a bit easier on this. > I tracked down the source from the ioctl call to the network driver > for some time now and could find no obvious fault, except for quite > much casting, and inconsistent use of types (checks happen on all > sorts of casts: socket, sokcet_dl, multiaddr, ...). It's quite possible that path is broken, as hardly anyone else out there needs to directly join a link-layer multicast group, and there is no regression test for it. The IP paths are known to work A-OK. If you didn't have code hooked up to ether_demux() to see this traffic, you'd never see it in userland anyway. As such, it's not a priority for me to fix , but will try to help anyway. Are there specific performance constraints for your app? If not you should just be able to use pcap (or bpf) to get the traffic. Admittedly this is a performance hit, but with the optimization work on bpf and ever more powerful CPUs, this shouldn't be a big issue. You can write a regression test for this though with getifmaddrs(). anglepoise:~/head/src/sys/net % s mtest Password: multicast membership test program; enter ? for list of commands a fxp0 01.80.c2.00.00.02 ether address added should yield route -nv monitor output got message of size 128 on Mon Feb 5 21:23:57 2007 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: <IFP,IFA> fxp0:0.90.27.59.40.2c 1.80.c2.0.0.2 Of course, netstat -g won't show you this, because it's concerned with IP/IPv6 only. netstat -ian should however tell you which link-layer multicast addresses are configured. When I add an ethernet multicast address manually with mtest, I see vmstat -m | grep ether_multi increment as I'd expect. It looks like there may be a missing piece somewhere. The code which I see is OK but the results aren't as I'd expect. I am quite tired at the moment so I may be way off. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45C7A1F9.20306>