History log of /freebsd/sys/net/if_bridge.c (Results 76 – 100 of 497)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 02ebdc78 31-Oct-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r307736 through r308146.


# 921e5f56 27-Oct-2016 Bryan Drewery <bdrewery@FreeBSD.org>

Remove excess CTLFLAG_VNET

Sponsored by: Dell EMC Isilon


Revision tags: release/11.0.1
# 8c4282b3 24-Sep-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r305892 through r306302.


# f18598a4 24-Sep-2016 Kristof Provost <kp@FreeBSD.org>

bridge: Fix fragment handling and memory leak

Fragmented UDP and ICMP packets were corrupted if a firewall with reassembling
feature (like pf'scrub) is enabled on the bridge. This patch fixes corru

bridge: Fix fragment handling and memory leak

Fragmented UDP and ICMP packets were corrupted if a firewall with reassembling
feature (like pf'scrub) is enabled on the bridge. This patch fixes corrupted
packet problem and the panic (triggered easly with low RAM) as explain in PR
185633.

bridge_pfil and bridge_fragment relationship:

bridge_pfil() receive (IN direction) packets and sent it to the firewall The
firewall can be configured for reassembling fragmented packet (like pf'scrubing)
in one mbuf chain when bridge_pfil() need to send this reassembled packet to the
outgoing interface, it needs to re-fragment it by using bridge_fragment()
bridge_fragment() had to split this mbuf (using ip_fragment) first then
had to M_PREPEND each packet in the mbuf chain for adding Ethernet
header.

But M_PREPEND can sometime create a new mbuf on the begining of the mbuf chain,
then the "main" pointer of this mbuf chain should be updated and this case is
tottaly forgotten. The original bridge_fragment code (Revision 158140,
2006 April 29) came from OpenBSD, and the call to bridge_enqueue was
embedded. But on FreeBSD, bridge_enqueue() is done after bridge_fragment(),
then the original OpenBSD code can't work as-it of FreeBSD.

PR: 185633
Submitted by: Olivier Cochard-Labbé
Differential Revision: https://reviews.freebsd.org/D7780

show more ...


Revision tags: release/11.0.0
# 84e63372 18-Jul-2016 Alexander Motin <mav@FreeBSD.org>

Negotiate/disable TXCSUM_IPV6 same as TXCSUM.


# 89856f7e 21-Jun-2016 Bjoern A. Zeeb <bz@FreeBSD.org>

Get closer to a VIMAGE network stack teardown from top to bottom rather
than removing the network interfaces first. This change is rather larger
and convoluted as the ordering requirements cannot be

Get closer to a VIMAGE network stack teardown from top to bottom rather
than removing the network interfaces first. This change is rather larger
and convoluted as the ordering requirements cannot be separated.

Move the pfil(9) framework to SI_SUB_PROTO_PFIL, move Firewalls and
related modules to their own SI_SUB_PROTO_FIREWALL.
Move initialization of "physical" interfaces to SI_SUB_DRIVERS,
move virtual (cloned) interfaces to SI_SUB_PSEUDO.
Move Multicast to SI_SUB_PROTO_MC.

Re-work parts of multicast initialisation and teardown, not taking the
huge amount of memory into account if used as a module yet.

For interface teardown we try to do as many of them as we can on
SI_SUB_INIT_IF, but for some this makes no sense, e.g., when tunnelling
over a higher layer protocol such as IP. In that case the interface
has to go along (or before) the higher layer protocol is shutdown.

Kernel hhooks need to go last on teardown as they may be used at various
higher layers and we cannot remove them before we cleaned up the higher
layers.

For interface teardown there are multiple paths:
(a) a cloned interface is destroyed (inside a VIMAGE or in the base system),
(b) any interface is moved from a virtual network stack to a different
network stack ("vmove"), or (c) a virtual network stack is being shut down.
All code paths go through if_detach_internal() where we, depending on the
vmove flag or the vnet state, make a decision on how much to shut down;
in case we are destroying a VNET the individual protocol layers will
cleanup their own parts thus we cannot do so again for each interface as
we end up with, e.g., double-frees, destroying locks twice or acquiring
already destroyed locks.
When calling into protocol cleanups we equally have to tell them
whether they need to detach upper layer protocols ("ulp") or not
(e.g., in6_ifdetach()).

Provide or enahnce helper functions to do proper cleanup at a protocol
rather than at an interface level.

Approved by: re (hrs)
Obtained from: projects/vnet
Reviewed by: gnn, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6747

show more ...


# a4641f4e 03-May-2016 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/net*: minor spelling fixes.

No functional change.


# 0edd2576 16-Apr-2016 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: The FreeBSD Foundation


# 155d72c4 15-Apr-2016 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/net* : for pointers replace 0 with NULL.

Mostly cosmetical, no functional change.

Found with devel/coccinelle.


Revision tags: release/10.3.0, release/10.2.0
# 416ba5c7 22-Jun-2015 Navdeep Parhar <np@FreeBSD.org>

Catch up with HEAD (r280229-r284686).


# 76aeda8a 20-Jun-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r284188 through r284643.


# dad2fb7e 15-Jun-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 581e6970 13-Jun-2015 Kristof Provost <kp@FreeBSD.org>

Fix panic when adding vtnet interfaces to a bridge

vtnet interfaces are always in promiscuous mode (at least if the
VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on
a

Fix panic when adding vtnet interfaces to a bridge

vtnet interfaces are always in promiscuous mode (at least if the
VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on
a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This
confused the bridge code. Instead we now accept all enable/disable promiscuous
commands (and always keep IFF_PROMISC set).

There are also two issues with the if_bridge error handling.

If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to
disable promiscuous mode on the interface. That runs into an assert, because
promiscuous mode was never set in the first place. (That's the panic reported in
PR 200210.)
We can only unset promiscuous mode if the interface actually is promiscuous.
This goes against the reference counting done by if_promisc(), but only the
first/last if_promic() calls can actually fail, so this is safe.

A second issue is a double free of bif. It's already freed by
bridge_delete_member().

PR: 200210
Differential Revision: https://reviews.freebsd.org/D2804
Reviewed by: philip (mentor)

show more ...


# 37a48d40 28-May-2015 Glen Barber <gjb@FreeBSD.org>

MFH: r282615-r283655

Sponsored by: The FreeBSD Foundation


# 98e0ffae 27-May-2015 Simon J. Gerraty <sjg@FreeBSD.org>

Merge sync of head


# 1c27e6c3 12-May-2015 Hiroki Sato <hrs@FreeBSD.org>

Fix a panic when VIMAGE is enabled.

Spotted by: Nikos Vassiliadis


# fa1e92b6 04-Mar-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 072aeeb6 02-Mar-2015 Navdeep Parhar <np@FreeBSD.org>

Merge r278538 through r279514.


# 6c787c8f 18-Feb-2015 Glen Barber <gjb@FreeBSD.org>

MFH: r278593-r278966

Sponsored by: The FreeBSD Foundation


# 714e3c81 17-Feb-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r278756 through r278915.


# 25792b11 14-Feb-2015 Hiroki Sato <hrs@FreeBSD.org>

Fix a panic when tearing down a vnet on a VIMAGE-enabled kernel.
There was a race that bridge_ifdetach() could be called via
ifnet_departure event handler after vnet_bridge_uninit().

PR: 195859
Rep

Fix a panic when tearing down a vnet on a VIMAGE-enabled kernel.
There was a race that bridge_ifdetach() could be called via
ifnet_departure event handler after vnet_bridge_uninit().

PR: 195859
Reported by: Danilo Egea Gondolfo

show more ...


# d899be7d 19-Jan-2015 Glen Barber <gjb@FreeBSD.org>

Reintegrate head: r274132-r277384

Sponsored by: The FreeBSD Foundation


# 8f0ea33f 13-Jan-2015 Glen Barber <gjb@FreeBSD.org>

Reintegrate head revisions r273096-r277147

Sponsored by: The FreeBSD Foundation


# 9268022b 19-Nov-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge from head@274682


Revision tags: release/10.1.0
# a9413f6c 08-Nov-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r274297.


12345678910>>...20