On Wed, Aug 29, 2007 at 06:31:11PM +0200, Johannes Berg wrote: > Looking through the receive code, the bridge_packets config option has > the effect of copying multicast traffic to the air right away and > passing frames to a station without having them go all the way through > the network stack. Yes or to be more exact, this is always enabled by default, so the effect of disabling this would be to stop copying received frames back to wireless interface immediately. > I think there's a flaw with this: when you turn it off, nothing will > copy multicast frames to the network as expected by an AP, as far as I > can tell. Hence, I think that the bridge_packets must not be honoured > for multicast packets. 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). Multicast packets from other interfaces (e.g., wired Ethernet) would go through to the wireless clients regardless of the bridge_packets option. > OTOH, for multicast, is it actually correct? Doesn't the AP need to > rewrite some fields? Yes, the 802.11 header changes, but this is taken care of by "bridging" the frame after the header conversion to 802.3. When the frame is going back up through the master interface, it will be converted to 802.11 header with the correct header fields. > As for unicast packets, what is the gain? There's obviously the loss > that netfilter won't see the packet which is generally very much frowned > upon. Is the performance benefit really that high? The gain of what? Enabling bridge_packets? Disabling bridge_packets? The benefit of enabling it is to make things actually work ;-). 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. 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). Disabling bridge_packets would be the option that some networks (e.g., public hotspots) might prefer to isolate the clients from other associated clients. Not that this is secure in an unencrypted network, but anyway, public hotspot would be the most likely user of bridge_packets=0. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
