netdev - Re: Port STP state after removing port from 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: <54E56C6A.1060108@cumulusnetworks.com>
Date:	Wed, 18 Feb 2015 20:54:02 -0800
From:	roopa <roopa@...ulusnetworks.com>
To:	Florian Fainelli <f.fainelli@...il.com>
CC:	Scott Feldman <sfeldma@...il.com>,
	Jiří Pírko <jiri@...nulli.us>,
	netdev <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: Port STP state after removing port from bridge

On 2/18/15, 8:39 PM, Florian Fainelli wrote:
> Hi,
>
> It just occured to me that the following sequence:
>
> brctl addbr br0
> brctl addif br0 port0
> ... STP happens
> brctl delif br0 port0
>
> will leave port0 in STP disabled state, because the bridge code will
> set the STP state to DISABLED, and only a down/up sequence can bring
> it back to FORWARDING.
>
> Is this something that we should somehow fix? As an user it seems a
> little convoluted having to do a down/up sequence to restore things. I
> believe however that it is valid for the bridge layer to mark a port
> as DISABLED when removing it. This is typically not noticed or even
> remotely a problem with software bridges because we cannot enforce an
> actual STP state at the HW level.
>
Just curious, Are you only talking about hw state being left it DISABLED 
state in the switchdev context ?.
If yes, then cant the switch driver who is already listening to port 
leave msgs, clear the disabled state on the port. ?
--
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