netdev - Re: IGMP joins come from the wrong SA/interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 31 Jan 2014 10:51:53 +0200 (EET)
From:	Julian Anastasov <ja@....bg>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
cc:	"Steinar H. Gunderson" <sgunderson@...foot.com>,
	netdev@...r.kernel.org
Subject: Re: IGMP joins come from the wrong SA/interface


	Hello,

On Thu, 30 Jan 2014, Hannes Frederic Sowa wrote:

> On Thu, Jan 30, 2014 at 07:12:29PM +0100, Steinar H. Gunderson wrote:
> > On Thu, Jan 30, 2014 at 04:08:11PM -0200, Flavio Leitner wrote:
> > > No special multicast route, so it should go out on em1/default route.
> > 
> > Well, that's not really relevant for my bug then, is it? My problem is that
> > it goes out on the default unicast route, whereas it shouldn't.
> 
> Hmm, it looks to me that Flavio showed that it should actually work
> correctly.
> 
> > > Maybe your application is using wrong values to IP_MULTICAST_IF?
> > > strace and /proc/net/igmp as suggested might help you find out.
> > 
> > This goes for at least vlc+mplayer+xbmc. I don't think they would all be
> > buggy in the same way? (Actually I don't think any of them set
> > IP_MULTICAST_IF.)
> 
> The routing lookup is done at IP_ADD_MEMBERSHIP time. I really wonder why you
> have routed the 239.0.0.0/8 range to eth0.11. It seems to me that the kernel
> does what you told it to do. ;)
> 
> multicast flag on ip route is just used for multicast forwarding and does not
> matter for local multicast. Also if we find unicast route first (more
> specific) kernel does not do backtracking if destination is in multicast
> scope.

	May be it is a side-effect of how inet_select_addr()
works. Looking at igmpv3_newpack() it tries to send packet
on the concerned interface (selected with IP_ADD_MEMBERSHIP)
to 224.0.0.22.

	IP_ADD_MEMBERSHIP selects interface, not source.
>From the provided strace output ip_mc_find_dev() should use
ip_route_output() because imr_address is 0 and imr_ifindex
is not provided. We get the eth0.11 interface from the
239.0.0.0/8 route.

	Then IGMP really wants to use the selected
interface but the configuration tries to use different
interfaces for both multicasts. IGMP simply does not
use FIB to select address because flowi4_oif is always
provided, so the multicast 224.0.0.0/4 route is not used
for the application.

	For ipv4_is_local_multicast (224.0.0.22) we call
inet_select_addr(dev_out, 0, RT_SCOPE_LINK) to select
saddr (link or global, not host) from eth0.11.

	Steinar, now 'ip addr show' can give more information
about what source is to be selected.

	It is possible the concerned interface (eth0.11 for
239.0.0.0/8 or another) to be without addresses. Then
inet_select_addr() can try to select address from another
interface as long as there is address with scope < RT_SCOPE_LINK,
eg. scope global. Order of interfaces matters only here.

	Is 178.82.50.98 on eth0.11 or on first interface?

	To summarize: IGMP will use the same interface as
selected from route to the joined multicast group but
source can be from another device if for some reason there
is no address on this interface.

Regards

--
Julian Anastasov <ja@....bg>
--
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