Date: Sat, 17 Feb 2007 18:26:13 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Jouke Witteveen <j.witteveen@gmail.com> Cc: freebsd-net@freebsd.org Subject: [PATCH] Re: ioctl: SIOCADDMULTI (howto?) Message-ID: <45D748C5.6040904@FreeBSD.org> In-Reply-To: <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> <45C7A1F9.20306@FreeBSD.org> <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------020907090605090509040208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jouke Witteveen wrote:
>
> 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.
That's a big relief! I added an item to the Wiki for someone to write a
regression test.
>
> 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.
I think I see a possible problem, though the code looks as though it is
behaving as expected.
I am looking at RELENG_6 if.c. I think sa_equal() may be to blame.
sa_equal() performs a binary comparison on all of sa_data up to sa_len.
Looking at struct sockaddr_dl, this might not be the right thing at all
in that situation... though I need another pair of eyes to look. Can
anyone shed light on this? An AF_INET and AF_INET6 address can be
completely specified and compared with sa_equal(). An AF_LINK address
looks as though sa_equal() may return irrational results.
>
> 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).
I wrote the libc getifmaddrs() function and integrated it into netstat
-g; Harti Brandt wrote the NET_RT_IFMALIST support. getifmaddrs()
*should* return sockaddr_dl as well as sockaddr_in and all the others.
netstat skips over AF_LINK addresses. Try this patch to reveal them. It
doesn't seem to show the IPv4 link layer memberships underneath, which
is interesting...
>
> 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.
Give it a try anyway! I like to think we have strong healthy egos round
here.
Regards,
BMS
--------------020907090605090509040208
Content-Type: text/x-patch;
name="llmcast.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="llmcast.diff"
--- mcast.c.orig Sat Feb 17 18:12:28 2007
+++ mcast.c Sat Feb 17 18:14:15 2007
@@ -84,7 +84,7 @@
if (getifmaddrs(&ifmap))
err(EX_OSERR, "getifmaddrs");
- fputs("IPv4/IPv6 Multicast Group Memberships\n", stdout);
+ fputs("IPv4/IPv6/Layer 2 Multicast Group Memberships\n", stdout);
fprintf(stdout, "%-20s\t%-16s\t%s\n", "Group", "Gateway", "Netif");
for (ifma = ifmap; ifma; ifma = ifma->ifma_next) {
@@ -103,6 +103,15 @@
inet_ntop(psa->sa.sa_family, addr, addrbuf,
sizeof(addrbuf));
pgroup = addrbuf;
+ break;
+ case AF_LINK:
+ if (psa->sdl.sdl_type == IFT_ETHER) {
+ plladdr = ether_ntoa((struct ether_addr *)
+ &psa->sdl.sdl_data);
+ } else {
+ plladdr = link_ntoa(&psa->sdl);
+ }
+ strlcpy(addrbuf, plladdr, sizeof(addrbuf));
break;
default:
continue; /* XXX */
--------------020907090605090509040208--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D748C5.6040904>