netdev - Re: [PATCH net-next] ipv6: addrconf: fix mcast route for GRE devices

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:	Wed, 30 Jul 2014 18:31:40 +0200
From:	David Lamparter <equinox@...c24.net>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	David Lamparter <equinox@...c24.net>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH net-next] ipv6: addrconf: fix mcast route for GRE devices

On Wed, Jul 30, 2014 at 06:09:27PM +0200, Hannes Frederic Sowa wrote:
[cut]
> > On Wed, Jul 30, 2014 at 05:14:42PM +0200, Hannes Frederic Sowa wrote:
> > > On Mi, 2014-07-30 at 02:55 +0200, David Lamparter wrote:
> > > > GRE devices, for some reason, were coming up with an autoconfigured
> > > > address, but no ff00::/8 route in the local table.  This breaks any kind
> > > > of multicast, in particular OSPFv3, mDNS, - and ND.  In fact, IPv6 only
> > > > works at all because there is little need for ND on PtP devices.
> > > > 
> > > > Adding any other IPv6 address on the device would rectify this issue
> > > > through inet6_addr_add()/addrconf_add_dev() - and would leave the route
> > > > around even if the address was later removed.  (This is probably why
> > > > this issue was not discovered earlier.  AFAICS it has been there from
> > > > the beginning, e.g. aee80b5 "generate link local address for GRE
> > > > tunnel")
> > > 
> > > Yep, this is poor, but changing this will break user space...
> > 
> > How exactly will this break user space?
> 
> Because the multicast routes will always be restored after e.g. a route
> flush or manual route deletion. Scripts might depend on this.

Sorry, I still don't get it.  Without this patch you end up in an
inconsistent state, where a LL addr exists, but multicast doesn't work
(since ff00::/8 is missing from RT6_TABLE_LOCAL).

Userspace is not supposed to touch RT6_TABLE_LOCAL in general, and, the
kernel will actually refuse installing the ff00::/8 route into the local
table from userspace (because there will be other ff00::/8 routes from
other interfaces, so you get "File exists").  You can delete the route
(and thus break mcast), but not add it.  The only way to add it is to
add an address.

Not changing this behaviour keeps breaking userspace;  ospf6d among
other things assumes an interface has working IPv6 when a link-local
address is present.


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