On Sat, 26 Mar 2005 23:40:30 +0100
Alpt [off-list ref] wrote:

Bridge hub_enabled patch:
this patch adds the hub_enabled option for bridge.

By default the hub_enabled flag is set to 1. In this case nothing changes, the
bridge, as usually, acts as a hub and flood_forward the input pkts to all its
ports. When hun_enabled is set to 0, the bridge stops to flood_forward the input
traffic and takes only the pkts sent to it.
Disabling the hub option is useful to join multiple interfaces into a unique virtual
one, thus becomes possible to have easily an ad-hoc network topology using multiple
interfaces.

Could you give a better example of how this would be useful?
Why would you not want A to talk to C? 
Why not enforce the policy with ebtables?

For example:


	A(eth0) --- (eth1)B(eth0) --- (eth1)C
		       BRIDGE
		       NO HUB
		        br0
A and C must not be directly connected, and B must have only one interface, in
this case br0.
This scenario is possible only disabling the hub behavior of the bridge.

To clarify, this topology is the same of having:

	A(wlan0)\	     /(wlan0)C
		 \	    /
		  \	   /
		    (wlan0)
		      B
A and C don't see each other.


Maybe the hub_enabled option may be useful for something else ^_-

The patch is simple and stupid, and it seems to work.

Also, since you broken the connectivity, anybody who is using multiple bridges
and spanning tree is going to create dead zones.