bridge packets option

bridge packets option

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Hey,

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.

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.

OTOH, for multicast, is it actually correct? Doesn't the AP need to
rewrite some 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?

I really need more devices for testing :/

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: bridge packets option

[Jouni Malinen]

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

Re: bridge packets option

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: bridge packets option

[Jouni Malinen]

On Tue, Sep 04, 2007 at 04:22:22PM +0200, Johannes Berg wrote:
> On Mon, 2007-09-03 at 16:57 -0700, Jouni Malinen wrote:

> > 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?

Well, it may be possible, but that would not be the way IEEE 802.11
access points normally work. AP is a layer 2 bridge and it should bridge
the packets regardless of what ethertype is used. There is no need for
it to keep up ARP tables for the associated stations to figure out where
to route packets. Furthermore, I would rather not see ICMP redirects
showing up on the wireless interface because IP routing needed to send
the packet back to the same interface. I would assume that this can be
disabled, but anyway, layer 2 bridge is the location that would be much
close to what AP does between two associated wireless stations.

-- 
Jouni Malinen                                            PGP id EFC895FA