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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGVrzcZMV3vSd3hEsXqk6BtyU-Ts9=oJvb79DTZp25TnnGm5CQ@mail.gmail.com>
Date:	Wed, 18 Feb 2015 20:39:55 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Scott Feldman <sfeldma@...il.com>,
	Jiří Pírko <jiri@...nulli.us>,
	netdev <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Port STP state after removing port from bridge

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.

Let me know your thoughts.
-- 
Florian
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ