linux-toradex.git/net/bridge, branch v2.6.27.50

netfilter: ebtables: enforce CAP_NET_ADMIN

2010-01-18T18:33:47+00:00

commit dce766af541f6605fa9889892c0280bab31c66ab upstream.

normal users are currently allowed to set/modify ebtables rules.
Restrict it to processes with CAP_NET_ADMIN.

Note that this cannot be reproduced with unmodified ebtables binary
because it uses SOCK_RAW.

Signed-off-by: Florian Westphal 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

netfilter: bridge: refcount fix

2009-10-05T15:11:48+00:00

netfilter: bridge: refcount fix

Upstream commit f3abc9b9:

commit f216f082b2b37c4943f1e7c393e2786648d48f6f
([NETFILTER]: bridge netfilter: deal with martians correctly)
added a refcount leak on in_dev.

Instead of using in_dev_get(), we can use __in_dev_get_rcu(),
as netfilter hooks are running under rcu_read_lock(), as pointed
by Patrick.

Signed-off-by: Eric Dumazet 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

bridge: bad error handling when adding invalid ether address

2009-05-02T17:23:47+00:00

[ Upstream commit cda6d377ec6b2ee2e58d563d0bd7eb313e0165df ]

This fixes an crash when empty bond device is added to a bridge.
If an interface with invalid ethernet address (all zero) is added
to a bridge, then bridge code detects it when setting up the forward
databas entry. But the error unwind is broken, the bridge port object
can get freed twice: once when ref count went to zeo, and once by kfree.
Since object is never really accessible, just free it.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: netfilter: fix update_pmtu crash with GRE

2009-03-17T00:52:41+00:00

[ Upstream commit 631339f1e544a4d39a63cfe6708c5bddcd5a2c48 ]

As GRE tries to call the update_pmtu function on skb->dst and
bridge supplies an skb->dst that has a NULL ops field, all is
not well.

This patch fixes this by giving the bridge device an ops field
with an update_pmtu function.  For the moment I've left all
other fields blank but we can fill them in later should the
need arise.

Based on report and patch by Philip Craig.

Signed-off-by: Herbert Xu 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: don't allow setting hello time to zero

2008-09-08T20:46:54+00:00

Dushan Tcholich reports that on his system ksoftirqd can consume
between %6 to %10 of cpu time, and cause ~200 context switches per
second.

He then correlated this with a report by bdupree@techfinesse.com:

	http://marc.info/?l=linux-kernel&m=119613299024398&w=2

and the culprit cause seems to be starting the bridge interface.
In particular, when starting the bridge interface, his scripts
are specifying a hello timer interval of "0".

The bridge hello time can't be safely set to values less than 1
second, otherwise it is possible to end up with a runaway timer.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

bridge: show offload settings

2008-08-16T02:51:07+00:00

Add more ethtool generic operations to dump the bridge offload
settings.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

bridge: Eliminate unnecessary forward delay

2008-08-06T01:42:51+00:00

From: Stephen Hemminger 

Based upon original patch by Herbert Xu, which contained
the following problem description:

--------------------
When the forward delay is set to zero, we still delay the setting
of the forwarding state by one or possibly two timers depending
on whether STP is enabled.  This could either turn out to be
instantaneous, or horribly slow depending on the load of the
machine.

As there is nothing preventing us from enabling forwarding straight
away, this patch eliminates this potential delay by executing the
code directly if the forward delay is zero.

The effect of this problem is that immediately after the carrier
comes on a port, the bridge will drop all packets received from
that port until it enters forwarding mode, thus causing unnecessary
packet loss.

Note that this patch doesn't fully remove the delay due to the
link watcher.  We should also check the carrier state when we
are about to drop an incoming packet because the port is disabled.
But that's for another patch.
--------------------

This version of the fix takes a different approach, in that
it just does the state change directly.

Signed-off-by: David S. Miller

bridge: fix compile warning in net/bridge/br_netfilter.c

2008-08-05T08:21:22+00:00

This patch fixes the following warning due to incompatible pointer
assignment:

net/bridge/br_netfilter.c: In function 'br_netfilter_rtable_init':
net/bridge/br_netfilter.c:116: warning: assignment from incompatible
pointer type

This warning is due to commit 4adf0af6818f3ea52421dc0bae836cfaf20ef72a
from July 30 (send correct MTU value in PMTU (revised)).

Signed-off-by: Rami Rosen 
Signed-off-by: David S. Miller

bridge: send correct MTU value in PMTU (revised)

2008-07-30T23:27:55+00:00

When bridging interfaces with different MTUs, the bridge correctly chooses
the minimum of the MTUs of the physical devices as the bridges MTU.  But
when a frame is passed which fits through the incoming, but not through
the outgoing interface, a "Fragmentation Needed" packet is generated.

However, the propagated MTU is hardcoded to 1500, which is wrong in this
situation.  The sender will repeat the packet again with the same frame
size, and the same problem will occur again.

Instead of sending 1500, the (correct) MTU value of the bridge is now sent
via PMTU.  To achieve this, the corresponding rtable structure is stored
in its net_bridge structure.

Modified to get rid of fake_net_device as well.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

netfilter: ebtables: use nf_register_hooks()

2008-07-27T00:47:53+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller