History log of /freebsd/sys/net/if_bridge.c (Results 51 – 75 of 497)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2aaf9152 18-Mar-2019 Alan Somers <asomers@FreeBSD.org>

MFHead@r345275


# 4920f9a3 15-Mar-2019 Kyle Evans <kevans@FreeBSD.org>

if_bridge(4): Drop pointless rtflush

At this point, all routes should've already been dropped by removing all
members from the bridge. This condition is in-fact KASSERT'd in the line
immediately abo

if_bridge(4): Drop pointless rtflush

At this point, all routes should've already been dropped by removing all
members from the bridge. This condition is in-fact KASSERT'd in the line
immediately above where this nop flush was added.

show more ...


# 6e6b93fe 15-Mar-2019 Kyle Evans <kevans@FreeBSD.org>

Revert r345192: Too many trees in play for bridge(4) bits

An accidental appendage was committed that has not undergone review yet.


# 4b4b284d 15-Mar-2019 Kyle Evans <kevans@FreeBSD.org>

if_bridge(4): Drop pointless rtflush

At this point, all routes should've already been dropped by removing all
members from the bridge. This condition is in-fact KASSERT'd in the line
immediately abo

if_bridge(4): Drop pointless rtflush

At this point, all routes should've already been dropped by removing all
members from the bridge. This condition is in-fact KASSERT'd in the line
immediately above where this nop flush was added.

show more ...


# 43d3127c 15-Mar-2019 Kristof Provost <kp@FreeBSD.org>

bridge: Fix STP-related panic

After r345180 we need to have the appropriate vnet context set to delete an
rtnode in bridge_rtnode_destroy().
That's usually the case, but not when it's called by the

bridge: Fix STP-related panic

After r345180 we need to have the appropriate vnet context set to delete an
rtnode in bridge_rtnode_destroy().
That's usually the case, but not when it's called by the STP code (through
bstp_notify_rtage()).

We have to set the vnet context in bridge_rtable_expire() just as we do in the
other STP callback bridge_state_change().

Reviewed by: kevans

show more ...


# a87407ff 15-Mar-2019 Kyle Evans <kevans@FreeBSD.org>

if_bridge(4): Fix module teardown

bridge_rtnode_zone still has outstanding allocations at the time of
destruction in the current model because all of the interface teardown
happens in a VNET_SYSUNIN

if_bridge(4): Fix module teardown

bridge_rtnode_zone still has outstanding allocations at the time of
destruction in the current model because all of the interface teardown
happens in a VNET_SYSUNINIT, -after- the MOD_UNLOAD has already been
processed. The SYSUNINIT triggers destruction of the interfaces, which then
attempts to free the memory from the zone that's already been destroyed, and
we hit a panic.

Solve this by virtualizing the uma_zone we allocate the rtnodes from to fix
the ordering. bridge_rtable_fini should also take care to flush any
remaining routes that weren't taken care of when dynamic routes were flushed
in bridge_stop.

Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D19578

show more ...


# 6b7e0c1c 14-Mar-2019 Kyle Evans <kevans@FreeBSD.org>

ether: centralize fake hwaddr generation

We currently have two places with identical fake hwaddr generation --
if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other
interfaces that ma

ether: centralize fake hwaddr generation

We currently have two places with identical fake hwaddr generation --
if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other
interfaces that may also need a fake addr.

Reviewed by: bryanv, kp, philip
Differential Revision: https://reviews.freebsd.org/D19573

show more ...


# b18a4cca 05-Mar-2019 Enji Cooper <ngie@FreeBSD.org>

MFhead@r344786


# c3c93809 04-Mar-2019 Alexander Motin <mav@FreeBSD.org>

bridge: Fix spurious warnings about capabilities

Mask off the bits we don't care about when checking that capabilities
of the member interfaces have been disabled as intended.

Submitted by: Ryan Mo

bridge: Fix spurious warnings about capabilities

Mask off the bits we don't care about when checking that capabilities
of the member interfaces have been disabled as intended.

Submitted by: Ryan Moeller <ryan@ixsystems.com>
Reviewed by: kristof, mav
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D18924

show more ...


# c2c227a5 03-Feb-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r343571 through r343711.


# b252313f 01-Feb-2019 Gleb Smirnoff <glebius@FreeBSD.org>

New pfil(9) KPI together with newborn pfil API and control utility.

The KPI have been reviewed and cleansed of features that were planned
back 20 years ago and never implemented. The pfil(9) intern

New pfil(9) KPI together with newborn pfil API and control utility.

The KPI have been reviewed and cleansed of features that were planned
back 20 years ago and never implemented. The pfil(9) internals have
been made opaque to protocols with only returned types and function
declarations exposed. The KPI is made more strict, but at the same time
more extensible, as kernel uses same command structures that userland
ioctl uses.

In nutshell [KA]PI is about declaring filtering points, declaring
filters and linking and unlinking them together.

New [KA]PI makes it possible to reconfigure pfil(9) configuration:
change order of hooks, rehook filter from one filtering point to a
different one, disconnect a hook on output leaving it on input only,
prepend/append a filter to existing list of filters.

Now it possible for a single packet filter to provide multiple rulesets
that may be linked to different points. Think of per-interface ACLs in
Cisco or Juniper. None of existing packet filters yet support that,
however limited usage is already possible, e.g. default ruleset can
be moved to single interface, as soon as interface would pride their
filtering points.

Another future feature is possiblity to create pfil heads, that provide
not an mbuf pointer but just a memory pointer with length. That would
allow filtering at very early stages of a packet lifecycle, e.g. when
packet has just been received by a NIC and no mbuf was yet allocated.

Differential Revision: https://reviews.freebsd.org/D18951

show more ...


Revision tags: release/12.0.0
# 14b841d4 11-Aug-2018 Kyle Evans <kevans@FreeBSD.org>

MFH @ r337607, in preparation for boarding


# 5f901c92 24-Jul-2018 Andrew Turner <andrew@FreeBSD.org>

Use the new VNET_DEFINE_STATIC macro when we are defining static VNET
variables.

Reviewed by: bz
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16147


Revision tags: release/11.2.0
# 5c30b378 11-May-2018 Matt Macy <mmacy@FreeBSD.org>

Allow different bridge types to coexist

if_bridge has a lot of limitations that make it scale poorly to higher data
rates. In my projects/VPC branch I leverage the bridge interface between
layers fo

Allow different bridge types to coexist

if_bridge has a lot of limitations that make it scale poorly to higher data
rates. In my projects/VPC branch I leverage the bridge interface between
layers for my high speed soft switch as well as for purposes of stacking
in general.

Reviewed by: sbruno@
Approved by: sbruno@
Differential Revision: https://reviews.freebsd.org/D15344

show more ...


# 0437c8e3 11-Apr-2018 Brooks Davis <brooks@FreeBSD.org>

Remove support for FDDI networks.

Defines in net/if_media.h remain in case code copied from ifconfig is in
use elsewere (supporting non-existant media type is harmless).

Reviewed by: kib, jhb
Spons

Remove support for FDDI networks.

Defines in net/if_media.h remain in case code copied from ifconfig is in
use elsewere (supporting non-existant media type is harmless).

Reviewed by: kib, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15017

show more ...


# effaab88 23-Mar-2018 Kristof Provost <kp@FreeBSD.org>

netpfil: Introduce PFIL_FWD flag

Forwarded packets passed through PFIL_OUT, which made it difficult for
firewalls to figure out if they were forwarding or producing packets. This in
turn is an issue

netpfil: Introduce PFIL_FWD flag

Forwarded packets passed through PFIL_OUT, which made it difficult for
firewalls to figure out if they were forwarding or producing packets. This in
turn is an issue for pf for IPv6 fragment handling: it needs to call
ip6_output() or ip6_forward() to handle the fragments. Figuring out which was
difficult (and until now, incorrect).
Having pfil distinguish the two removes an ugly piece of code from pf.

Introduce a new variant of the netpfil callbacks with a flags variable, which
has PFIL_FWD set for forwarded packets. This allows pf to reliably work out if
a packet is forwarded.

Reviewed by: ae, kevans
Differential Revision: https://reviews.freebsd.org/D13715

show more ...


# fe267a55 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
pro

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

show more ...


# c2c014f2 07-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r323559 through r325504.


Revision tags: release/10.4.0
# e5d34ca9 23-Sep-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r320180


# ed9de14d 21-Sep-2017 Kristof Provost <kp@FreeBSD.org>

bridge: Set module version

This ensures that the loader will not load the module if it's also built in to
the kernel.

PR: 220860
Submitted by: Eugene Grosbein <eugen@freebsd.org>
Reported by: Mari

bridge: Set module version

This ensures that the loader will not load the module if it's also built in to
the kernel.

PR: 220860
Submitted by: Eugene Grosbein <eugen@freebsd.org>
Reported by: Marie Helene Kvello-Aune <marieheleneka@gmail.com>

show more ...


Revision tags: release/11.1.0
# be27b311 04-May-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r317503 through r317807.


# ebe42881 29-Apr-2017 Alexander Motin <mav@FreeBSD.org>

Make if_bridge complain if it can't disable some capabilities.

MFC after: 2 weeks
Sponsored by: iXsystems, Inc.


# 9b3ece1c 04-Feb-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r313243


# 14f850f3 27-Jan-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r312720 through r312893.


# ab5cda71 25-Jan-2017 Kristof Provost <kp@FreeBSD.org>

bridge: Release the bridge lock when calling bridge_set_ifcap()

This calls ioctl() handlers for the different interfaces in the bridge.
These handlers expect to get called in an ioctl context where

bridge: Release the bridge lock when calling bridge_set_ifcap()

This calls ioctl() handlers for the different interfaces in the bridge.
These handlers expect to get called in an ioctl context where it's safe
for them to sleep. We may not sleep with the bridge lock held.

However, we still need to protect the interface list, to ensure it
doesn't get changed while we iterate over it.
Use BRIDGE_XLOCK(), which prevents bridge members from being removed.
Adding bridge members is safe, because it uses LIST_INSERT_HEAD().

This caused panics when adding xen interfaces to a bridge.

PR: 216304
Reviewed by: ae
MFC after: 1 week
Sponsored by: RootBSD
Differential Revision: https://reviews.freebsd.org/D9290

show more ...


12345678910>>...20