netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julian Anastasov <ja@ssi.bg>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: "Steinar H. Gunderson" <sgunderson@bigfoot.com>, netdev@vger.kernel.org
Subject: Re: IGMP joins come from the wrong SA/interface
Date: Fri, 31 Jan 2014 10:51:53 +0200 (EET)	[thread overview]
Message-ID: <alpine.LFD.2.11.1401310948270.1576@ja.home.ssi.bg> (raw)
In-Reply-To: <20140130224411.GG25336@order.stressinduktion.org>


	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@ssi.bg>

  reply	other threads:[~2014-01-31  8:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-18 19:11 IGMP joins come from the wrong SA/interface Steinar H. Gunderson
2014-01-18 19:17 ` Steinar H. Gunderson
2014-01-19 18:18 ` Hannes Frederic Sowa
2014-01-20 18:40   ` Steinar H. Gunderson
2014-01-30 10:47     ` Steinar H. Gunderson
2014-01-30 14:17       ` Hannes Frederic Sowa
2014-01-30 20:31         ` Steinar H. Gunderson
2014-01-30 18:08       ` Flavio Leitner
2014-01-30 18:12         ` Steinar H. Gunderson
2014-01-30 22:44           ` Hannes Frederic Sowa
2014-01-31  8:51             ` Julian Anastasov [this message]
2014-01-31 11:32               ` Hannes Frederic Sowa
2014-02-04 22:08             ` Steinar H. Gunderson
2014-02-04 23:32               ` Hannes Frederic Sowa
2014-02-04 23:34                 ` Steinar H. Gunderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.11.1401310948270.1576@ja.home.ssi.bg \
    --to=ja@ssi.bg \
    --cc=hannes@stressinduktion.org \
    --cc=netdev@vger.kernel.org \
    --cc=sgunderson@bigfoot.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).