Would appreciate some guidance on this. It seems like a reasonably serious
regression, so I’m surprised it hasn’t already been fixed.
Since all of our code binds a particular library, we were able to work around
it by overriding the weak referenced socket() with our own version that creates
th
This revision was automatically updated to reflect the committed changes.
Closed by commit rS324673: mbuf(9): unbreak m_fragment() (authored by avos,
committed by ).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D4090?vs=9973&id=34038#toc
REPOSITORY
rS FreeBSD src repository
CHANGES S
On Mon, Oct 16, 2017 at 04:22:04PM +0200, Marko Cupać wrote:
> Hi,
>
> I have already asked this on -jail two weeks ago, but perhaps this is
> better place to ask.
>
> I notice wierd routing in my setfib (ez)jails setup.
>
> I have a server with multiple NICs. setfib should ensure that LAN jails
Karim,
On Mon, Oct 16, 2017 at 10:37:02AM -0400, Karim Fodil-Lemelin wrote:
K> > Not only mbufs of M_PKTHDR may have m_nextpkt set. However, I tend to agree
K> > with the patch. But shouldn't we first copy the m_nextpkt to the new mbuf:
K> >
K> > + to->m_nextpkt = from->m_nextpkt;
K> > + from-
On 2017-10-13 5:10 PM, Gleb Smirnoff wrote:
On Fri, Oct 13, 2017 at 12:59:47AM -0700, Adrian Chadd wrote:
A> When doing so m_move_pkthdr is called to copy the current PKTHDR fields
A> (tags and flags) to the mbuf that was prepended. The function also does:
A>
A> to->m_pkthdr =
Hi,
I have already asked this on -jail two weeks ago, but perhaps this is
better place to ask.
I notice wierd routing in my setfib (ez)jails setup.
I have a server with multiple NICs. setfib should ensure that LAN jails
(setfib 1) can not talk to DMZ jails (setfib 2) over loopbacks, but
need to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #13 from Heinz N. Gies ---
(In reply to Eugene Grosbein from comment #12)
ifconfig em0 (no bridge interfaces)
em0: flags=8943 metric 0 mtu
1500
options=4219b
ether 00:25:90:a6:3b:c7
hwaddr 00:25:90:a6:3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #12 from Eugene Grosbein ---
(In reply to Heinz N. Gies from comment #7)
> 2. Compare output of ifconfig $uplink before and after it added to the bridge.
... after it AND other members added to the bridge.
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #11 from Heinz N. Gies ---
Yes I read that, and I've been going through the man pages trying to figure out
which those are is there a list of settings supported by epairs. Just saw the
updated info bridge I think that's what I w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #10 from Eugene Grosbein ---
(In reply to Heinz N. Gies from comment #7)
Please repeat your tests being more thorough:
1. Verify if you still have the problem while adding second and next bridge
members after uplink interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:
Author: mav
Date: Mon Oct 16 12:32:57 UTC 2017
New revision: 324659
URL: https://svnweb.freebsd.org/changeset/base/324659
Log:
Update details of interface capa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #8 from Alexander Motin ---
(In reply to Heinz N. Gies from comment #7)
Bridge+epair are the right tools, unless you wish to dedicate one NIC
completely to specific VNET Jail.
I've already told you how to workaround the problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #7 from Heinz N. Gies ---
(In reply to Eugene Grosbein from comment #6)
> Addition of first member to the bridge is quite different from addition of
> others. Why do you think it interferes with traffic flow every time?
Mostl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Eugene Grosbein changed:
What|Removed |Added
Summary|Attatching vnet interfaces |Attaching interface to a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Eugene Grosbein changed:
What|Removed |Added
Summary|Attaching interface to a|Attatching vnet interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Alexander Motin changed:
What|Removed |Added
Summary|Attatching vnet interfaces |Attaching interface to a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Alexander Motin changed:
What|Removed |Added
Summary|Attatching vnet interfaces |Attatching vnet interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #5 from Alexander Motin ---
OK, we call it any way you like, but it does not change the facts: to be able
bridge interfaces with different hardware capabilities, some of those
capabilities has to be disabled, and changing capabi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Heinz N. Gies changed:
What|Removed |Added
Summary|Attatching vxlan interfaces |Attatching vnet interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Heinz N. Gies changed:
What|Removed |Added
Resolution|Works As Intended |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Alexander Motin changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #2 from Heinz N. Gies ---
Hi, first of all, thanks for looking into this! It does sound like an
explanation for what I'm seeing. I sadly know little about the internals of the
network stack, but the symptoms seem to fit. Adding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
Alexander Motin changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #1
24 matches
Mail list logo
