Date: Sat, 17 Feb 2007 14:46:47 +0100 From: "Jouke Witteveen" <j.witteveen@gmail.com> To: "Bruce M. Simpson" <bms@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: ioctl: SIOCADDMULTI (howto?) Message-ID: <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> In-Reply-To: <45C7A1F9.20306@FreeBSD.org> References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> <45C7A1F9.20306@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/5/07, Bruce M. Simpson <bms@freebsd.org> wrote: > 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 > Further investigation showed that the address gets to the driver just fine. I also saw with tcpdump that it actualy works: with `tcpdump -i dc0 -p multicast` I could see traffic that I didn't see when I hadn't added the multicast address. So my apologies for suggesting it doesn't work at all; it seems that the application I'm trying to get to work (wpa_supplicant for wired interfaces) just doesn't _send_ its packets the right way. Things aren't perfect though. In if.c the if_findmulti function is broken (always returns NULL). I presume just comparing the *LLADDR((sockaddr *)sa) data on both sockets is a better check, though my knowledge on these things is limited. As for netstat, I do not really know what is keeping it from showing the Multicast addresses. Again: my knowledge on this matter is limited. All I can think of is that getifmaddrs is forgetting something (perhaps the lack of a group membership). Maybe you can take a look at it (I believe you wrote it). As I am still learning how best to contribute to a project as big as FreeBSD and I do not think I am skilled enough yet in C I refrain from writing a patch. I am eager to see one though, be it only out of curiosity to know what would be considered a proper fix. I hope someone can find a spare minute to look at if_findmulti. It would help me quite much. Kind regards, - Jouke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3993a4980702170546t7f9384eaq358986a4cc734582>