similar to: [Bridge] received packet with own address as source address

Changes since v9: * series re-ordering so make functionality more distinct. Basic vlan filtering is patches 1-4. Support for PVID/untagged vlans is patches 5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is still additional egress policy. * Slight simplification to code that extracts the VID from skb. Since we now depend on the vlan module, at the time of input skb_tci is

This allows the called fdb_create to detect that the entry was added by the user early in the process. This is in preparation to adding limits in fdb_create that should not apply to user created fdb entries. Signed-off-by: Johannes Nixdorf <jnixdorf-oss at avm.de> --- Changes since v1: - Added this change to ensure user added entries are not limited. net/bridge/br_fdb.c | 6 +++--- 1

hi, I'm getting registration errors I can't debug... [Mar 23 11:07:20] NOTICE[2952]: chan_iax2.c:7344 socket_process: Registration of 'host2' rejected: 'Registration Refused' from: '10.10.10.82' I was getting a 'Cause Code: 29' INV,POKE,...,REJ but I can't duplicate that level of debugging again in the CLI> on host15 10.10.10.15

I'm debugging a strange problem of noncommunication between two devices. The test configuration is also strange, and involves loops. Things magically start working when I run tcpdump to put the bridge interface into promiscuous mode. I also noticed this in the output of brctl showmacs. port no mac addr is local? ageing timer 1 00:40:72:04:2d:ea no

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become

Introduce a limit on the amount of learned FDB entries on a bridge, configured by netlink with a build time default on bridge creation in the kernel config. For backwards compatibility the kernel config default is disabling the limit (0). Without any limit a malicious actor may OOM a kernel by spamming packets with changing MAC addresses on their bridge port, so allow the bridge creator to limit

To be able to add dynamic FDB entries to drivers from userspace, the dynamic flag must be added when sending RTM_NEWNEIGH events down. Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> --- include/net/switchdev.h | 1 + net/bridge/br_switchdev.c | 1 + 2 files changed, 2 insertions(+) diff --git a/include/net/switchdev.h b/include/net/switchdev.h index

On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: > To be able to add dynamic FDB entries to drivers from userspace, the > dynamic flag must be added when sending RTM_NEWNEIGH events down. > > Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> > --- > include/net/switchdev.h | 1 + > net/bridge/br_switchdev.c | 1 + > 2 files changed, 2

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

On Mon, Mar 27, 2023 at 14:52, Vladimir Oltean <olteanv at gmail.com> wrote: > > By the way, there is a behavior change here. > > Before: > > $ ip link add br0 type bridge && ip link set br0 up > $ ip link set swp0 master br0 && ip link set swp0 up > $ bridge fdb add dev swp0 00:01:02:03:04:05 master dynamic > [ 70.010181] mscc_felix 0000:00:00.5:

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

Convert the bridge forwarding database over to using RCU. This avoids a read_lock and atomic_inc/dec in the fast path of output. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> diff -Nru a/include/linux/list.h b/include/linux/list.h --- a/include/linux/list.h 2004-07-28 15:30:04 -07:00 +++ b/include/linux/list.h 2004-07-28 15:30:04 -07:00 @@ -678,6 +678,24 @@ pos &&

There is a structural problem in switchdev, where the flag bits in struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only represent a simplified / denatured view of what's in struct net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc). Each time we want to pass more information about struct net_bridge_fdb_entry :: flags to struct switchdev_notifier_fdb_info

On Tue, Jan 17, 2023 at 07:57:11PM +0100, Hans J. Schultz wrote: > Dynamic FDB flag needs to be propagated through the DSA layer to be > added to drivers. > Use a u16 for fdb flags for future use, so that other flags can also be > sent the same way without having to change function interfaces. > > Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> > ---

On Mon, Mar 27, 2023 at 05:31:26PM +0200, Hans Schultz wrote: > On Mon, Mar 27, 2023 at 14:52, Vladimir Oltean <olteanv at gmail.com> wrote: > > > > By the way, there is a behavior change here. > > > > Before: > > > > $ ip link add br0 type bridge && ip link set br0 up > > $ ip link set swp0 master br0 && ip link set swp0 up >

On 2023-01-18 00:17, Vladimir Oltean wrote: > On Tue, Jan 17, 2023 at 07:57:11PM +0100, Hans J. Schultz wrote: >> Dynamic FDB flag needs to be propagated through the DSA layer to be >> added to drivers. >> Use a u16 for fdb flags for future use, so that other flags can also >> be >> sent the same way without having to change function interfaces. >> >>

On 2023-01-18 00:08, Vladimir Oltean wrote: > On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: >> To be able to add dynamic FDB entries to drivers from userspace, the >> dynamic flag must be added when sending RTM_NEWNEIGH events down. >> >> Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> >> --- >>