public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Wang Xingtong <wangxingtong@cn•fujitsu.com>
To: David Miller <davem@davemloft•net>
Cc: gaofeng@cn•fujitsu.com, netdev@vger•kernel.org
Subject: Re: [PATCH V2] IPv6 : add multicast routing verify which net_device is lo
Date: Wed, 21 Dec 2011 17:01:21 +0800	[thread overview]
Message-ID: <4EF1A061.5030005@cn.fujitsu.com> (raw)
In-Reply-To: <20111221.011506.1770356582907889299.davem@davemloft.net>


> From: Gao feng <gaofeng@cn•fujitsu.com>
> Date: Tue, 20 Dec 2011 19:10:24 +0800
> 
>> In currently routing subsystem, when we lookup a multicast routing
>> to send muticast packets to outside, rt6_device_match will return
>> the rt6_info which it's match first. If we add a multicast route on
>> loopback devices beforce the others interface, rt6_device_match will
>> retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
>> we can't send a muticast packet to outside using loopback devices.
>> It case all multicast packets blocking.
>>
>> Commit 4af04aba93f47699e disabled kernel add multicast route on lo
>> automatically. However,  we can't surmise the routing-add order or
>> interdict add multicast routing on loopback devices in user space.
>> The bug still exist. So, i think, more stronger routing subsystem is
>> necessary.
>>
>> Signed-off-by: Wang xingtong <wangxingtong@cn•fujitsu.com>
> 
> Ok, this is getting rediculious.  I want to revert all of this
> stuff.
> 
> How about, instead, we stop userland adding explicit addresses to the
> loopback device since that's what started behaving differently
> recently and causes these problems in the first place?

OK, David, I reproduce this as following :

1) ip -6 route show | grep ff00
    unreachable ff00::/8 dev lo  metric 1024  error -101
    ff00::/8 dev eth1  metric 1024

2) ip -6 route del ff00::/8 dev eth1
    ip -6 route del ff00::/8 dev lo

3) ip -6 route add ff00::/8 dev lo
    ip -6 route add ff00::/8 dev eth1

now, if we join to the multicast group with the interface index is 
specified as 0, not restrict devices( oif == 0 ), not restrict saddr ( 
saddr == :: ), rt6_device_match  will return rt6_info which 
rt6i_dev->name is "lo" all the while, and rt6i_dev->error is
"-ENETUNREACH".  we got "ENODEV" at userspace,  all multicast packets 
will be blocked .

But, in fact, eth1 can be uesd and we missed. This is a bug in routing 
system, isn't it?

This patch add multicast routing check-up in rt6_device_match to arrest
it return loopback device when we isn't specified interface and saddr.

thanks,

wang xingtong

  reply	other threads:[~2011-12-21  9:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-20  6:13 [PATCH] IPv6 : add multicast routing verify which net_device is lo Wang Xingtong
2011-12-20  9:47 ` Wang Xingtong
2011-12-20 11:10   ` [PATCH V2] " Gao feng
2011-12-21  6:15     ` David Miller
2011-12-21  9:01       ` Wang Xingtong [this message]
2011-12-21 19:11         ` David Miller

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=4EF1A061.5030005@cn.fujitsu.com \
    --to=wangxingtong@cn$(echo .)fujitsu.com \
    --cc=davem@davemloft$(echo .)net \
    --cc=gaofeng@cn$(echo .)fujitsu.com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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