[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFDC1D2E6E.2DCF75EA-ON88257368.0053513A-88257368.005586DC@us.ibm.com>
Date: Tue, 2 Oct 2007 08:35:08 -0700
From: David Stevens <dlstevens@...ibm.com>
To: Dmitry Baryshkov <Dmitry.Baryshkov@...mens.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
netdev-owner@...r.kernel.org
Subject: Re: [PATCH] Fallback to ipv4 if we try to add join IPv4 multicast group via
ipv4-mapped address.
Dmitry,
Good catch; a couple comments:
> struct ipv6_pinfo *np = inet6_sk(sk);
> int err;
> + int addr_type = ipv6_addr_type(addr);
> +
> + if (addr_type == IPV6_ADDR_MAPPED) {
> + __be32 v4addr = addr->s6_addr32[3];
> + struct ip_mreqn mreq;
> + mreq.imr_multiaddr.s_addr = v4addr;
> + mreq.imr_address.s_addr = INADDR_ANY;
> + mreq.imr_ifindex = ifindex;
> +
> + return ip_mc_join_group(sk, &mreq);
> + }
ipv6_addr_type() returns a bitmask, so you should use:
if (addr_type & IPV6_ADDR_MAPPED) {
Also, you should have a blank line after the "mreq" declaration.
Ditto for both in ipv6_mc_sock_drop().
I don't expect the multicast source filtering interface will
behave well for mapped addresses, either. The mapped multicast
address won't appear to be a multicast address (and return
error there), and all the source filters would have to be
v4mapped addresses and modify the v4 source filters for this
to do as you expect. So, there's more to it (and it may be a
bit messy) to support mapped multicast addresses fully. I'll
think about that part some more.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists