netdev - Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.

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:	Thu, 08 Dec 2011 08:58:21 +0800
From:	Li Wei <lw@...fujitsu.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] ipv6: Fix for adding multicast route for loopback device
 automatically.

David Miller wrote:
> From: Li Wei <lw@...fujitsu.com>
> Date: Wed, 07 Dec 2011 15:23:45 +0800
> 
>> There is no obvious reason to add a default multicast route for loopback
>> devices, otherwise there would be a route entry whose dst.error set to
>> -ENETUNREACH that would blocking all multicast packets.
>>
>> Signed-off-by: Li Wei <lw@...fujitsu.com>
> 
> I still do not understand the purpose of this change, what problems
> does the current behavior cause?

Hi, David, thank you for your comment.

The problem is that the resulting routing table depends on the sequence
of interface's initialization and in some situation, that would block all
muticast packets. Suppose there are two interfaces on my computer
(lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
table(for multicast) would be

# ip -6 route show | grep ff00::
unreachable ff00::/8 dev lo metric 256 error -101
ff00::/8 dev eth0 metric 256

When sending multicasting packets, routing subsystem will return the first
route entry which with a error set to -101(ENETUNREACH).

I know the kernel will set the default ipv6 address for 'lo' when it is up
and won't set the default multicast route for it, but there is no reason to
stop 'init' program from setting address for 'lo', and that is exactly what
systemd did.

I am sure there is something wrong with kernel or systemd, currently I preferred
kernel caused this problem.

> 
> And can you be sure that by making this change, you are not breaking
> something, somewhere, that depends upon the current behavior?
> 
> 

I can't see there is any reason to set a default multicast route for loopback device
*automatically*. 

Thanks, 
Wei

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