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$(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