ioctl: SIOCADDMULTI (howto?)

[Jouke Witteveen]

On 2/5/07, Bruce M. Simpson <bms at 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