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