On Sat, 26 Mar 2005 23:40:30 +0100 Alpt <alpt@xxxxxxxxxxxx> 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.