netdev - Re: [PATCH 1/2] bridge: leave carrier on for empty bridge

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]

Message-ID: <20110904093634.685d7c56@nehalam.ftrdhcpuser.net>
Date:	Sun, 4 Sep 2011 09:36:34 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] bridge: leave carrier on for empty bridge

On Sun, 04 Sep 2011 09:35:10 +0200
Nicolas de Pesloüan <nicolas.2p.debian@...il.com> wrote:

> Le 04/09/2011 06:14, Stephen Hemminger a écrit :
> 
> >> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
> >> following condition are true at the same time :
> >>
> >> - The bridge have no port.
> >> - At least one IP address is setup on the bridge.
> >> - The two above conditions are true for more than a configurable amount of seconds, with a default
> >> of 10, for example.
> >>
> >> This would only delay carrier on for a few seconds for the regression and keep the current behavior
> >> (carrier off until at least 1 port is on) for DHCP.
> >
> > This fails on two counts:
> > 1. Bridge's often run without IP addresses!
> > 2. DHCP won't try and send out request until carrier is true.
> 
> Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
> 
> And rethinking about it, the delay is probably useless :
> 
> bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port & bridge_has_at_least_one_ip)
> 
> That way :
> - for those using bridge without any port, manually setting the IP will assert carrier on. (By the 
> way, why don't they use a dummy device instead?)
> 
> - for those using bridge with ports:
> -- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time 
> first port get carrier.
> -- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the 
> small time gap between IP address configuration and first port is added to the bridge. This time gap 
> may be removed by simply configuring the IP after the first port is added. This is probably already 
> true for most distribs. And anyway, this time gap is probably not a problem.
> -- Carrier will also be erroneously reported as on after removing the last port, if the bridge still 
> has an IP. (But we can arrange for this not to happen).
> 
> And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO 
> message for the non-natural case (bridge_has_no_port & bridga_has_at_least_one_ip).
> 
> I consider all this reasonable.
> 
> 	Nicolas.

Any bridge behaviour based on IP address configuration is a
layering violation and won't work.  The problem is related to dynamic issues
with IPv6 and DHCP and needs to be addressed at that level.

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