On Mon, 2007-09-03 at 16:57 -0700, Jouni Malinen wrote: > This is by design and in most cases you would not disable > bridge_packets. This option is to allow the AP to be configured in a > mode where wireless stations are more isolated from each other, i.e., if > the multicast source were indeed the wireless client associated to the > AP, other associated clients would not see these frames (unless > something else in the network stack were configured to push them back to > the same interface which is less likely to happen). Ah, I see, ok. > Multicast packets > from other interfaces (e.g., wired Ethernet) would go through to the > wireless clients regardless of the bridge_packets option. Right, if bridged with wireless. > The gain of what? Enabling bridge_packets? Disabling bridge_packets? The > benefit of enabling it is to make things actually work ;-). Heh, right. > Kernel > bridging code does not (or at least did not the last time I looked) > allow packets to be bridged back to the same interface which would be > needed for the case of two wireless stations which are associated to the > same AP sending packets to each other. I was thinking more of routing in the unicast case, if a packet comes in you'd have to route it back to wireless if the destination is there. Isn't that possible? > If the bridging code were to be changed to be more aware of 802.11 > interface, I would be happy to get rid of the bridge_packet=1 code in > mac80211. If I remember correctly, a patch for doing this was submitted > long time ago and there has been some discussions on this topic, but not > much progress on this area has happened. Consequently, all 802.11 AP > implementations will need to continue doing this in the 802.11 code (or > by using a patched bridge code or custom module for doing this somewhere > else). Thanks, I'll look it up. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
