On Sun, 27 Mar 2005, Alpt wrote:
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.
Won't this bite you if the destination MAC has expired from the bridge forwarding table?
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.
I don't quite get this..
To clarify, this topology is the same of having:
A(wlan0)\ /(wlan0)C \ / \ / (wlan0) B A and C don't see each other.
IMHO for this function you should use netfilter to deny forwarding of traffic between the two wlan interfaces, not change the bridge core to behave oddly.
Making the bridge based router not flood forward unknown destinations doesn't really accomplish the above as it only changes the behaviour of not yet seen destination MAC addresses and broadcasts (where broadcasts is your main concern I think). The two will still be able to communicate as soon as they learn each others MAC provided both are active on the network (seen in the bridge forwarding table)
Regards Henrik - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
