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
next prev parent 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.fujitsu.com \
--cc=davem@davemloft.net \
--cc=gaofeng@cn.fujitsu.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.