linux.git/net/bridge/br_device.c, branch v4.3

net: bridge: convert to using IFF_NO_QUEUE

2015-08-18T18:55:06+00:00

Signed-off-by: Phil Sutter 
Cc: Stephen Hemminger 
Signed-off-by: David S. Miller

bridge: Don't segment multiple tagged packets on bridge device

2015-08-03T21:24:50+00:00

Bridge devices don't need to segment multiple tagged packets since thier
ports can segment them.

Signed-off-by: Toshiaki Makita 
Signed-off-by: David S. Miller

netfilter: bridge: use rcu hook to resolve br_netfilter dependency

2015-03-10T14:03:02+00:00

e5de75b ("netfilter: bridge: move DNAT helper to br_netfilter") results
in the following link problem:

net/bridge/br_device.c:29: undefined reference to `br_nf_prerouting_finish_bridge`

Moreover it creates a hard dependency between br_netfilter and the
bridge core, which is what we've been trying to avoid so far.

Resolve this problem by using a hook structure so we reduce #ifdef
pollution and keep bridge netfilter specific code under br_netfilter.c
which was the original intention.

Reported-by: Simon Horman 
Signed-off-by: Pablo Neira Ayuso

netfilter: bridge: move DNAT helper to br_netfilter

2015-03-09T16:56:07+00:00

Only one caller, there is no need to keep this in a header.
Move it to br_netfilter.c where this belongs to.

Based on patch from Florian Westphal.

Signed-off-by: Pablo Neira Ayuso

bridge: Add filtering support for default_pvid

2014-10-06T01:21:37+00:00

Currently when vlan filtering is turned on on the bridge, the bridge
will drop all traffic untill the user configures the filter.  This
isn't very nice for ports that don't care about vlans and just
want untagged traffic.

A concept of a default_pvid was recently introduced.  This patch
adds filtering support for default_pvid.   Now, ports that don't
care about vlans and don't define there own filter will belong
to the VLAN of the default_pvid and continue to receive untagged
traffic.

This filtering can be disabled by setting default_pvid to 0.

Signed-off-by: Vladislav Yasevich 
Signed-off-by: David S. Miller

netfilter: bridge: move br_netfilter out of the core

2014-09-26T16:42:31+00:00

Jesper reported that br_netfilter always registers the hooks since
this is part of the bridge core. This harms performance for people that
don't need this.

This patch modularizes br_netfilter so it can be rmmod'ed, thus,
the hooks can be unregistered. I think the bridge netfilter should have
been a separated module since the beginning, Patrick agreed on that.

Note that this is breaking compatibility for users that expect that
bridge netfilter is going to be available after explicitly 'modprobe
bridge' or via automatic load through brctl.

However, the damage can be easily undone by modprobing br_netfilter.
The bridge core also spots a message to provide a clue to people that
didn't notice that this has been deprecated.

On top of that, the plan is that nftables will not rely on this software
layer, but integrate the connection tracking into the bridge layer to
enable stateful filtering and NAT, which is was bridge netfilter users
seem to require.

This patch still keeps the fake_dst_ops in the bridge core, since this
is required by when the bridge port is initialized. So we can safely
modprobe/rmmod br_netfilter anytime.

Signed-off-by: Pablo Neira Ayuso 
Acked-by: Florian Westphal

bridge: Prepare for forwarding another bridge group addresses

2014-06-11T22:22:53+00:00

If a bridge is an 802.1ad bridge, it must forward another bridge group
addresses (the Nearest Customer Bridge group addresses).
(For details, see IEEE 802.1Q-2011 8.6.3.)

As user might not want group_fwd_mask to be modified by enabling 802.1ad,
introduce a new mask, group_fwd_mask_required, which indicates addresses
the bridge wants to forward. This will be set by enabling 802.1ad.

Signed-off-by: Toshiaki Makita 
Signed-off-by: David S. Miller

bridge: Prepare for 802.1ad vlan filtering support

2014-06-11T22:22:53+00:00

This enables a bridge to have vlan protocol informantion and allows vlan
tag manipulation (retrieve, insert and remove tags) according to the vlan
protocol.

Signed-off-by: Toshiaki Makita 
Signed-off-by: David S. Miller

bridge: Add 802.1ad tx vlan acceleration

2014-06-11T22:22:53+00:00

Bridge device doesn't need to embed S-tag into skb->data.

Signed-off-by: Toshiaki Makita 
Signed-off-by: David S. Miller

bridge: Automatically manage port promiscuous mode.

2014-05-16T21:06:33+00:00

There exist configurations where the administrator or another management
entity has the foreknowledge of all the mac addresses of end systems
that are being bridged together.

In these environments, the administrator can statically configure known
addresses in the bridge FDB and disable flooding and learning on ports.
This makes it possible to turn off promiscuous mode on the interfaces
connected to the bridge.

Here is why disabling flooding and learning allows us to control
promiscuity:
 Consider port X.  All traffic coming into this port from outside the
bridge (ingress) will be either forwarded through other ports of the
bridge (egress) or dropped.  Forwarding (egress) is defined by FDB
entries and by flooding in the event that no FDB entry exists.
In the event that flooding is disabled, only FDB entries define
the egress.  Once learning is disabled, only static FDB entries
provided by a management entity define the egress.  If we provide
information from these static FDBs to the ingress port X, then we'll
be able to accept all traffic that can be successfully forwarded and
drop all the other traffic sooner without spending CPU cycles to
process it.
 Another way to define the above is as following equations:
    ingress = egress + drop
 expanding egress
    ingress = static FDB + learned FDB + flooding + drop
 disabling flooding and learning we a left with
    ingress = static FDB + drop

By adding addresses from the static FDB entries to the MAC address
filter of an ingress port X, we fully define what the bridge can
process without dropping and can thus turn off promiscuous mode,
thus dropping packets sooner.

There have been suggestions that we may want to allow learning
and update the filters with learned addresses as well.  This
would require mac-level authentication similar to 802.1x to
prevent attacks against the hw filters as they are limited
resource.

Additionally, if the user places the bridge device in promiscuous mode,
all ports are placed in promiscuous mode regardless of the changes
to flooding and learning.

Since the above functionality depends on full static configuration,
we have also require that vlan filtering be enabled to take
advantage of this.  The reason is that the bridge has to be
able to receive and process VLAN-tagged frames and the there
are only 2 ways to accomplish this right now: promiscuous mode
or vlan filtering.

Suggested-by: Michael S. Tsirkin 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller