[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110926130507.1435d76b@nehalam.linuxnetplumber.net>
Date: Mon, 26 Sep 2011 13:05:07 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Nicolas de Pesloüan
<nicolas.2p.debian@...il.com>
Cc: Marc Haber <mh+netdev@...schlus.de>, netdev@...r.kernel.org
Subject: Re: Bridge stays down until a port is added
On Mon, 26 Sep 2011 22:02:21 +0200
Nicolas de Pesloüan <nicolas.2p.debian@...il.com> wrote:
> Le 26/09/2011 17:47, Stephen Hemminger a écrit :
> > The root of this whole problem is really that IPv6 reports addresses
> > in a tentative state to applications that can not be passed to the bind() system call.
> > For most cases, this problem never happens because the tentative addresses are
> > resolved by Duplicate Address Detection before the application starts. But
> > I have seen (and fixed) this happen before this whole discussion started.
> >
> > 1. The problem is not unique to bridges. It happens with bridge, macvtap,
> > even on wireless networks where the device is available but carrier is
> > not asserted.
> >
> > 2. Any change to what the kernel does (like not reporting tentative addresses)
> > would break applications even worse.
> >
> > 3. When the bridge was always reporting carrier, it was in effect breaking
> > IPv6 Duplicate Address Detection. And that is bad.
>
> Stephen,
>
> What do you think about a generic per-interface option that would cause bind() to accept tentative
> address hold by a particular interface? This of course violate IPv6 principle, but we are talking
> about interfaces that are unable to do DAD, either permanently or until something happens on the
> underlying device.
>
> echo 1 > /sys/class/net/br0/allow_bind_on_tentative_address
> echo 1 > /sys/class/net/dummy0/allow_bind_on_tentative_address
> echo 1 > /sys/class/net/wlan0/allow_bind_on_tentative_address
> and so on...
>
> And we may possibly automatically reset this option to 0 if DAD eventually causes the address to be
> considered duplicate.
The issue is that if DAD rejects a duplicate, the socket is dead and application is
out of luck.
Has anyone looked at this issue in relation to systemd which does early
opportunistic binding of services?
--
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
Powered by blists - more mailing lists