In D14547#306213, @rstone wrote:

In D14547#305425, @rstone wrote:

And you do you insist in doing things manually while moving IP (first route change, then reassign IP) instead of just allowing system do all housekeeping for you by reassigning IP first?

What FreeBSD version (including revision) do you use for TEST PLAN script, e.g. what is your "stock FreeBSD"?

I vote to block it for now. We can re-think it in case some useful example of real case came up.

Indeed, people sometimes tend to do strange things with their network and that's nothing wrong with it (I do sometimes, too). But we should have a distinction for supported configuration and unsupported ones (leading to panic or anothe misbehavour). For example, we do not support assigning IP address to lagg or bridge member - one can do that but that won't work generally.

Why don't we just reject creation of vlan interface on lagg member (as opposed to lagg itself)?

Do you really need to mix whitespace change with the fix (last chunk)?

Initial submitter of the PR 224556 is a bit too rash.

In D13426#280534, @kib wrote:

Does this change break ABI or KBI ? Or both ?

In D13426#280611, @kib wrote:

In D13426#280595, @eugen_grosbein.net wrote:

nop and others not mentioned in the diff use "off_t" internaly already.

Look at the argument types for g_nop_create() as an example.

More changes: geom_nop, geom_stripe and geom_redboot.

In D13426#280612, @imp wrote:

In D13426#280534, @kib wrote:

Does this change break ABI or KBI ? Or both ?

In D13426#280534, @kib wrote:

Does this change break ABI or KBI ? Or both ?

Some providers take stripesize/offset in create, e.g. nop. Do they need a fix included into the change ?

DISK_VERSION bumped.

21.10.2017 4:41, bz (Bjoern A. Zeeb) пишет:

This revision was automatically updated to reflect the committed changes.
Closed by commit rS324810: With r181803 on 2008-08-17 23:27:27Z the first VIMAGE commit went into (authored by bz, committed by ).

CHANGED PRIOR TO COMMIT

https://reviews.freebsd.org/D12639?vs=33888&id=34199#toc

REPOSITORY

rS FreeBSD src repository

CHANGES SINCE LAST UPDATE

https://reviews.freebsd.org/D12639?vs=33888&id=34199

REVISION DETAIL

https://reviews.freebsd.org/D12639

In D12086#258234, @mav wrote:

Do you think the case when lower and orphan hooks are connected to the same node is realistic enough to make this code so tangled?

In D12086#258234, @mav wrote:

While I understand your valid motivation, I can't say that I very much like this in patch for several reasons:

• NGM_ETHER_SET_ENADDR is a control command supposed to be targeted to ng_ether node, not from it, and it is a action request, not notification.

Expand a comment explaining code.

In D12457#258249, @rwatson wrote:

Many of these changes are not sufficient to address the underlying problems in this code, as the lock covers loop iteration but fails to protect the stability of the 'ifp' or 'ia' pointer outside of the loop.

hook needs to be NULL-checked before refcounting.

No, I'm not asking for support that would take a few weeks of ping pong in a bug tracker, if any. This is real world feedback for this review. Take it or leave it. :)

In D9270#251108, @franco_opnsense.org wrote:

Thanks, but we've narrowed it down to this commit.

In D9270#251087, @franco_opnsense.org wrote:

We do seem to have a persistent problem with this patch in some PPPoE environments that will cause a crash in ng_pppoe_rcvdata_ether():

https://ibb.co/mRWKHF
https://ibb.co/iOxRxF
https://forum.opnsense.org/index.php?topic=5697.0

Please advise.

FreeBSD already has neened fuction, the change is not needed.

Cleanup this.

I'm seconding ae@: IPSEC_SUPPORT should remain, but IPSEC should be removed. The ipsec.ko and tcpmd5.ko should be loadable, not statically compiled in.

"ipfw fwd" does nothing with contents of packets. Apache determines contents to return, not ipfw fwd.
All you need it to properly configure Apache to match virtualhost right.

I wrote earlier "And kernel fixes (translates) replies so that they look as returning from port 3000". That was misprint, I meant to write "And kernel fixes (translates) replies so that they look as returning from port 80".

That is how it is supposed to work. An answer must be returned from the port if original request, or else client TCP stack would drop it instead of delivering to HTTP browser.

"ipfw fwd" works for me just fine in 11.1
What is an application do you have that listens for socket at port tcp/3000?
Why do you think that packets do not get redirected to its server socket?
For local redirect there is no port translation needed, the data just get delivered to the socket directly.

You can use any matching expression, it will work for "recv re1* dst-port 80" too.
You can use "ipfw fwd" to redirect packets to http server too, without transparent proxying.
It just works.

We already have "ipfw fwd" command for this task that works just fine and does not require any patches.

You should better describe a problem solved by this change.

My tests show no problems with this patch applied. It seems this is required for net/mpd5 to run stable, it hits lock leak in the stdio otherwise: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114#c83

I've applied this to my mpd server (libc rebuilt and reinstalled) and restarted my tests. Hope it won't crash :-)