subject:"On Netgraph"

[Bug 278130] [netgraph][patch] ng_bridge hooks should auto assign number for [up]link

2024-04-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278130

Gleb Smirnoff  changed:

   What|Removed |Added

   Assignee|n...@freebsd.org |gleb...@freebsd.org
 CC||gleb...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 278130] [netgraph][patch] ng_bridge hooks should auto assign number for [up]link

2024-04-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278130

--- Comment #2 from David Marker  ---
Added review D44615 as requested.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 278130] [netgraph][patch] ng_bridge hooks should auto assign number for [up]link

2024-04-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278130

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Re : Re: netgraph and vpp

2023-11-26 Thread Jim Thompson

On Nov 25, 2023 at 4:09:29 AM, Benoit Chesneau 
wrote:

>
> Thanks for your answer. So i guess if we want to build a modern router
> without custom code, vpp is the way to go in term de performance?
>

Well, that’s the path I chose back in 2016, yes.

(Might note that I also run the pfsense project, and that VPP does not
currently run on FreeBSD.)

One thing i really miss ito  cross connect 2 interfaces without using a
> bridge. Somethibg really easy and performant with  vpp...
>

kp@ added something similar using pf https://reviews.freebsd.org/D37193 but
if_bridge is pretty performant these days
https://issue.freebsdfoundation.org/publication/?i=660151


Benoit
> Le sam. 25 nov. 2023 à 00:33, Jim Thompson  nov. 2023 à 00:33, Jim Thompson <> a écrit :
>
>
>
> On Nov 24, 2023 at 12:48:07 AM, Benoit Chesneau <
> beno...@enki-multimedia.eu> wrote:
>
>> netgraph and vpp looks similar in their intent. Both are graphs to
>> process packets.
>>
>> I thought that usinv netgraph sounds interresting to build a modern
>> router or cpe. What about the perforance? Did anyone compRe? Also is there
>> any difference in term of implementation of the processing? Id there any
>> recent paper about netgraph?
>>
>
> They are very, very different. Netgraph is closer to AT streams, but
> with mbufs.
>
> Netgraph would probably be better implemented these days as a set of
> netmap modules, ala
> https://github.com/zeek/packet-bricks or
> https://github.com/outscale/packetgraph (this one is DPDK, but similar
> architecture)
>
>
>
>

Re : Re: netgraph and vpp

2023-11-25 Thread Benoit Chesneau

Thanks for your answer. So i guess if we want to build a modern router without 
custom code, vpp is the way to go in term de performance?

One thing i really miss ito cross connect 2 interfaces without using a bridge. 
Somethibg really easy and performant with vpp...

Benoit
Le sam. 25 nov. 2023 à 00:33, Jim Thompson <[j...@netgate.com](mailto:Le sam. 
25 nov. 2023 à 00:33, Jim Thompson < a écrit :

> On Nov 24, 2023 at 12:48:07 AM, Benoit Chesneau  
> wrote:
>
>> netgraph and vpp looks similar in their intent. Both are graphs to process 
>> packets.
>>
>> I thought that usinv netgraph sounds interresting to build a modern router 
>> or cpe. What about the perforance? Did anyone compRe? Also is there any 
>> difference in term of implementation of the processing? Id there any recent 
>> paper about netgraph?
>
> They are very, very different. Netgraph is closer to AT streams, but with 
> mbufs.
>
> Netgraph would probably be better implemented these days as a set of netmap 
> modules, ala
> https://github.com/zeek/packet-bricks or 
> https://github.com/outscale/packetgraph (this one is DPDK, but similar 
> architecture)

Re: netgraph and vpp

2023-11-24 Thread Jim Thompson

On Nov 24, 2023 at 12:48:07 AM, Benoit Chesneau 
wrote:

> netgraph and vpp looks similar in their intent. Both are graphs to
> process packets.
>
> I thought that usinv  netgraph sounds interresting to build a modern
> router or cpe. What about the perforance? Did anyone compRe? Also is there
> any difference in term of implementation of the processing? Id there any
> recent paper about netgraph?
>

They are very, very different.  Netgraph is closer to AT streams, but
with mbufs.

Netgraph would probably be better implemented these days as a set of netmap
modules, ala
https://github.com/zeek/packet-bricks or
https://github.com/outscale/packetgraph (this one is DPDK, but similar
architecture)

netgraph and vpp

2023-11-23 Thread Benoit Chesneau

netgraph and vpp looks similar in their intent. Both are graphs to process 
packets.

I thought that usinv  netgraph sounds interresting to build a modern router or 
cpe. What about the perforance? Did anyone compRe? Also is there any difference 
in term of implementation of the processing? Id there any recent paper about 
netgraph?

benoit

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

Re: performance of netgraph vs bridge

2023-10-08 Thread Goran Mekić


On 10/8/23 11:00, Benoit Chesneau wrote:
Before I am doing some performance tests myself, did someone comparend 
netgraph ng_bridge vs if_bridge with recent multi thread additions in 
netgraph ?


The advantage I see in using netgraph is remooving the need of using 
tap interfaces  and instead using netgraph sockets.  Which seems to be 
more integrated.


One of the issue I have with netgraph is its lack of inclusion in 
bastille.


Any feedback is welcome,

Benoît Chesneau, Enki Multimedia
—
t. +33608655490

Sent with Proton Mail <https://proton.me/> secure email.


https://klarasystems.com/articles/using-netgraph-for-freebsds-bhyve-networking/

performance of netgraph vs bridge

2023-10-08 Thread Benoit Chesneau

Before I am doing some performance tests myself, did someone comparend netgraph 
ng_bridge vs if_bridge with recent multi thread additions in netgraph ?

The advantage I see in using netgraph is remooving the need of using tap 
interfaces and instead using netgraph sockets. Which seems to be more 
integrated.

One of the issue I have with netgraph is its lack of inclusion in bastille.

Any feedback is welcome,

Benoît Chesneau, Enki Multimedia
—
t. +33608655490

Sent with [Proton Mail](https://proton.me/) secure email.

linux xdp vs netgraph

2023-10-05 Thread Benoit Chesneau

I may be wrong but xdp linux looks a lot like netgraph. Packets are processed 
at kernel level and we can chain instructions over them. Is there any 
comparison of their features around?

[Bug 223824] Panic in ng_base.c (netgraph)

2023-07-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223824

Graham Perrin  changed:

   What|Removed |Added

Summary|[arm64] Kernel panic in |Panic in ng_base.c
   |ng_base.c (netgraph)|(netgraph)
  Flags||mfc-stable13?

-- 
You are receiving this mail because:
You are the assignee for the bug.

bridging VLANs with netgraph(3)

2023-03-25 Thread Marek Zarychta


Dear subscribers of the list,

the scenario requires packets for one of the tagged VLANs to be copied 
in span mode, still tagged, to epair(4) interface for feeding IDS 
inside, but at least one additional vlan(4) inside the jail is required 
to provide network connectivity for the jail.


With a simple hack[1] of if_bridge(4) it's possible to have epair(4) 
interface being a member and a span port at once, so now I have:


bridge0: everything  *-->  epair0 | jail --> vlan1499 --> IDS 


bridge0: vlan 1000   <-->  epair0 | jail <-> vlan1000 <-> host access

The drawback of this solution is using patched sources and having 
duplicated packets for vlan1000 inside the jail, but the desired state is:


vlan 1499 *--> epair0
vlan 1000 <--> epair0


Any suggestions on how to make it work with netgraph(3) will be warmly 
appreciated.



[1] https://cgit.freebsd.org/src/tree/sys/net/if_bridge.c#n1206

Cheers

--
Marek Zarychta


OpenPGP_signature
Description: OpenPGP digital signature

[Bug 270083] [netgraph] ng_netflow, NetFlow v9: maximum packets count between re-announcing data templates is ignored

2023-03-12 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270083

Mark Linimon  changed:

   What|Removed |Added

 CC|n...@freebsd.org |
   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 270083] [netgraph] ng_netflow, NetFlow v9: maximum packets count between re-announcing data templates is ignored

2023-03-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270083

Marek Zarychta  changed:

   What|Removed |Added

 CC||n...@freebsd.org

--- Comment #1 from Marek Zarychta  ---
Unfortunately, the removal of code doing re-announcements on the basis of
packet counter, according to RFC 3954, is forbidden[1], so maybe our
respectable programmers can fix it. 

[1]   3. On a regular basis, the Exporter MUST send all the Template
  Records and Options Template Records to refresh the Collector.
  Template IDs have a limited lifetime at the Collector and MUST be
  periodically refreshed.  Two approaches are taken to make sure
  that Templates get refreshed at the Collector:
* Every N number of Export Packets.
* On a time basis, so every N number of minutes.
  Both options MUST be configurable by the user on the Exporter.
  When one of these expiry conditions is met, the Exporter MUST send
  the Template FlowSet and Options Template.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 237072] netgraph(4): performance issue [on HardenedBSD]?

2023-01-22 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237072

Graham Perrin  changed:

   What|Removed |Added

   See Also|https://github.com/Hardened |
   |BSD/hardenedBSD/issues/376  |
 CC||grahamper...@freebsd.org

--- Comment #15 from Graham Perrin  ---
(In reply to Larry Rosenman from comment #6)

 no longer presents issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 246706] [netgraph] kernel panic due to corrupted memory

2022-11-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246706

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||crash

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 246706] [netgraph] kernel panic due to corrupted memory

2022-10-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246706

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@freebsd.org
   Assignee|n...@freebsd.org |eu...@freebsd.org

--- Comment #3 from Graham Perrin  ---
^Triage: with closure, there should be assignment to a person.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 246706] [netgraph] kernel panic due to corrupted memory

2022-10-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246706

Eugene Grosbein  changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|Open|Closed

--- Comment #2 from Eugene Grosbein  ---
Does not reproduce with 11.4-STABLE (not tested with more recent versions).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-06-27 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Takanori Watanabe  changed:

   What|Removed |Added

  Flags|mfc-stable12?,  |mfc-stable12+,
   |mfc-stable11?   |mfc-stable11+
 Resolution|--- |FIXED
 Status|In Progress |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-06-27 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

--- Comment #8 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=7bbd5ebae80b52a87d62164a04221752efa8fd50

commit 7bbd5ebae80b52a87d62164a04221752efa8fd50
Author: Takanori Watanabe 
AuthorDate: 2021-05-26 09:23:33 +
Commit: Takanori Watanabe 
CommitDate: 2021-06-28 04:00:51 +

Fix a use-after-free in an error case.

PR: 255872
Submitted by:  lylgood
Differential Revision:  https://reviews.freebsd.org/D30454

(cherry picked from commit 14803ec8d193d8d46f4137a7dba61b277c6a2fed)

 sys/netgraph/bluetooth/hci/ng_hci_evnt.c | 1 +
 1 file changed, 1 insertion(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-06-27 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=766da930f994bc0fe27cc9235f0594a6c4e0a88f

commit 766da930f994bc0fe27cc9235f0594a6c4e0a88f
Author: Takanori Watanabe 
AuthorDate: 2021-05-26 09:23:33 +
Commit: Takanori Watanabe 
CommitDate: 2021-06-28 03:58:48 +

Fix a use-after-free in an error case.

PR: 255872
Submitted by:  lylgood
Differential Revision:  https://reviews.freebsd.org/D30454

(cherry picked from commit 14803ec8d193d8d46f4137a7dba61b277c6a2fed)

 sys/netgraph/bluetooth/hci/ng_hci_evnt.c | 1 +
 1 file changed, 1 insertion(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #11 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=4a0c1d0543afd83156b50b3f9b74c79e74cf526f

commit 4a0c1d0543afd83156b50b3f9b74c79e74cf526f
Author: Lutz Donnerhacke 
AuthorDate: 2021-06-02 22:29:46 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-16 11:48:22 +

tests/netgraph: Inital framework for testing libnetgraph

Provide a framework of functions to test various netgraph modules.
Tests contain:
 - creating, renaming, and destroying nodes
 - connecting and removing hooks
 - sending and receiving data
 - sending ASCII messages and receiving binary responses
 - errors can be passed for indiviual inspection or fail the test

Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D30629
Differential Revision: https://reviews.freebsd.org/D30657
Differential Revision: https://reviews.freebsd.org/D30671
Differential Revision: https://reviews.freebsd.org/D30699

(cherry picked from commit 24ea1dbf257aa6757f469bcd859f90e9ad851e59)
(cherry picked from commit 09307dbfb888a98232096c751a96ecb3344aa77c)
(cherry picked from commit 9021c46603bf29b9700f24b8dce8796b434d7c8f)
(cherry picked from commit 5554abd9cc9702af30af90925b33c5efff4e7d88)

Also contains some fixups:
 - indent all files correctly
 - finish factoring out
 - remove debugging code
 - check for renaming issues reported in PR241954

PR: 241954
Differential Revision: https://reviews.freebsd.org/D30692
Differential Revision: https://reviews.freebsd.org/D30714
Differential Revision: https://reviews.freebsd.org/D30713

(cherry picked from commit a664ade93972ce617f0888ff79e715dff9cf0f87)
(cherry picked from commit 0afa9be03937d60cb5aeba64c81e3e2165bd3737)
(cherry picked from commit 43e4821315c31db067e23564b9bfafb519e77b2b)

 tests/sys/netgraph/Makefile  |   6 +
 tests/sys/netgraph/basic.c (new) | 191 +++
 tests/sys/netgraph/util.c (new)  | 277 +++
 tests/sys/netgraph/util.h (new)  | 114 
 4 files changed, 588 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #10 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=2def8906341231cd6b3647756c182f60d114deee

commit 2def8906341231cd6b3647756c182f60d114deee
Author: Lutz Donnerhacke 
AuthorDate: 2021-06-02 22:29:46 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-16 11:44:15 +

tests/netgraph: Inital framework for testing libnetgraph

Provide a framework of functions to test various netgraph modules.
Tests contain:
 - creating, renaming, and destroying nodes
 - connecting and removing hooks
 - sending and receiving data
 - sending ASCII messages and receiving binary responses
 - errors can be passed for indiviual inspection or fail the test

Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D30629
Differential Revision: https://reviews.freebsd.org/D30657
Differential Revision: https://reviews.freebsd.org/D30671
Differential Revision: https://reviews.freebsd.org/D30699

(cherry picked from commit 24ea1dbf257aa6757f469bcd859f90e9ad851e59)
(cherry picked from commit 09307dbfb888a98232096c751a96ecb3344aa77c)
(cherry picked from commit 9021c46603bf29b9700f24b8dce8796b434d7c8f)
(cherry picked from commit 5554abd9cc9702af30af90925b33c5efff4e7d88)

Also contains some fixups:
 - indent all files correctly
 - finish factoring out
 - remove debugging code
 - check for renaming issues reported in PR241954

PR: 241954
Differential Revision: https://reviews.freebsd.org/D30692
Differential Revision: https://reviews.freebsd.org/D30714
Differential Revision: https://reviews.freebsd.org/D30713

(cherry picked from commit a664ade93972ce617f0888ff79e715dff9cf0f87)
(cherry picked from commit 0afa9be03937d60cb5aeba64c81e3e2165bd3737)
(cherry picked from commit 43e4821315c31db067e23564b9bfafb519e77b2b)

 tests/sys/netgraph/Makefile  |   6 +
 tests/sys/netgraph/basic.c (new) | 191 +++
 tests/sys/netgraph/util.c (new)  | 277 +++
 tests/sys/netgraph/util.h (new)  | 114 
 4 files changed, 588 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #9 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=36c7408818c53ae0c1f1aee0250c5d3fe16b06e0

commit 36c7408818c53ae0c1f1aee0250c5d3fe16b06e0
Author: Lutz Donnerhacke 
AuthorDate: 2021-06-02 22:29:46 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-15 12:31:32 +

tests/netgraph: Inital framework for testing libnetgraph

Provide a framework of functions to test various netgraph modules.
Tests contain:
 - creating, renaming, and destroying nodes
 - connecting and removing hooks
 - sending and receiving data
 - sending ASCII messages and receiving binary responses
 - errors can be passed for indiviual inspection or fail the test

Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D30629
Differential Revision: https://reviews.freebsd.org/D30657
Differential Revision: https://reviews.freebsd.org/D30671
Differential Revision: https://reviews.freebsd.org/D30699

(cherry picked from commit 24ea1dbf257aa6757f469bcd859f90e9ad851e59)
(cherry picked from commit 09307dbfb888a98232096c751a96ecb3344aa77c)
(cherry picked from commit 9021c46603bf29b9700f24b8dce8796b434d7c8f)
(cherry picked from commit 5554abd9cc9702af30af90925b33c5efff4e7d88)

Also contains some fixups:
 - indent all files correctly
 - finish factoring out
 - remove debugging code
 - check for renaming issues reported in PR241954

PR: 241954
Differential Revision: https://reviews.freebsd.org/D30692
Differential Revision: https://reviews.freebsd.org/D30714
Differential Revision: https://reviews.freebsd.org/D30713

(cherry picked from commit a664ade93972ce617f0888ff79e715dff9cf0f87)
(cherry picked from commit 0afa9be03937d60cb5aeba64c81e3e2165bd3737)
(cherry picked from commit 43e4821315c31db067e23564b9bfafb519e77b2b)

 tests/sys/netgraph/Makefile  |   6 +-
 tests/sys/netgraph/basic.c (new) | 191 +++
 tests/sys/netgraph/util.c (new)  | 277 +++
 tests/sys/netgraph/util.h (new)  | 114 
 4 files changed, 587 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #8 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=b57a593cb2d69a684e4be04e8cea7fe7a7f43b24

commit b57a593cb2d69a684e4be04e8cea7fe7a7f43b24
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-04 19:20:39 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-10 09:35:21 +

netgraph/ng_base: Renaming a node to the same name is a noop

Detailed analysis in
https://github.com/genneko/freebsd-vimage-jails/issues/2
brought the problem down to a double call of ng_node_name() before and
after a vnet move.  Because the name of the node is already known
(occupied by itself), the second call fails.

PR: 241954
Reported by:Paul Armstrong
Differential Revision: https://reviews.freebsd.org/D30110

(cherry picked from commit 0345fd891fe13a191fc0fae9463ea9458bfaff5a)

 sys/netgraph/ng_base.c | 4 
 1 file changed, 4 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Lutz Donnerhacke  changed:

   What|Removed |Added

  Flags|mfc-stable13?,  |mfc-stable13+,
   |mfc-stable12?,  |mfc-stable12+,
   |mfc-stable11?   |mfc-stable11+

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=a0694da5d035ea0e686ad1bae95709e52df0913a

commit a0694da5d035ea0e686ad1bae95709e52df0913a
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-04 19:20:39 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-10 09:33:19 +

netgraph/ng_base: Renaming a node to the same name is a noop

Detailed analysis in
https://github.com/genneko/freebsd-vimage-jails/issues/2
brought the problem down to a double call of ng_node_name() before and
after a vnet move.  Because the name of the node is already known
(occupied by itself), the second call fails.

PR: 241954
Reported by:Paul Armstrong
Differential Revision: https://reviews.freebsd.org/D30110

(cherry picked from commit 0345fd891fe13a191fc0fae9463ea9458bfaff5a)

 sys/netgraph/ng_base.c | 4 
 1 file changed, 4 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=37370a6773cde7fcae063aed0a4cc024f95534bd

commit 37370a6773cde7fcae063aed0a4cc024f95534bd
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-04 19:20:39 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-10 09:29:34 +

netgraph/ng_base: Renaming a node to the same name is a noop

Detailed analysis in
https://github.com/genneko/freebsd-vimage-jails/issues/2
brought the problem down to a double call of ng_node_name() before and
after a vnet move.  Because the name of the node is already known
(occupied by itself), the second call fails.

PR: 241954
Reported by:Paul Armstrong
Differential Revision: https://reviews.freebsd.org/D30110

(cherry picked from commit 0345fd891fe13a191fc0fae9463ea9458bfaff5a)

 sys/netgraph/ng_base.c | 4 
 1 file changed, 4 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-06-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Kubilay Kocak  changed:

   What|Removed |Added

 CC||m...@johnson.org
   Keywords|needs-qa|
 Resolution|FIXED   |---
 Status|Closed  |In Progress
   Assignee|ma...@freebsd.org   |takaw...@freebsd.org
  Flags|mfc-stable13?   |mfc-stable13+

--- Comment #6 from Kubilay Kocak  ---
^Triage: Assign to committer resolving, cc previous Assignee. Track stable
merge

Is this going to stable/{12,11}. If so, please close after merging and setting
mfc-* flags to +, otherwise set mfc_flags to - with comment

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-06-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=26c3e7a1ecb375de071786a07bdd68f867acdb3c

commit 26c3e7a1ecb375de071786a07bdd68f867acdb3c
Author: Takanori Watanabe 
AuthorDate: 2021-05-26 09:23:33 +
Commit: Takanori Watanabe 
CommitDate: 2021-06-09 05:20:57 +

Fix a use-after-free in an error case.

PR: 255872
Submitted by:  lylgood
Differential Revision:  https://reviews.freebsd.org/D30454

(cherry picked from commit 14803ec8d193d8d46f4137a7dba61b277c6a2fed)

 sys/netgraph/bluetooth/hci/ng_hci_evnt.c | 1 +
 1 file changed, 1 insertion(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph: Fails on concurrent node rename

2021-06-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Kubilay Kocak  changed:

   What|Removed |Added

Summary|netgraph fails on   |netgraph: Fails on
   |concurrent node rename  |concurrent node rename
URL||https://reviews.freebsd.org
   ||/D30110
   See Also||https://github.com/genneko/
   ||freebsd-vimage-jails/issues
   ||/2

--- Comment #5 from Kubilay Kocak  ---
^Triage: Re-open pending merges

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph fails on concurrent node rename

2021-06-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Lutz Donnerhacke  changed:

   What|Removed |Added

  Flags||mfc-stable13?,
   ||mfc-stable12?,
   ||mfc-stable11?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph fails on concurrent node rename

2021-06-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Lutz Donnerhacke  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 241954] netgraph fails on concurrent node rename

2021-06-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=0345fd891fe13a191fc0fae9463ea9458bfaff5a

commit 0345fd891fe13a191fc0fae9463ea9458bfaff5a
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-04 19:20:39 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-04 09:20:19 +

netgraph/ng_base: Renaming a node to the same name is a noop

Detailed analysis in
https://github.com/genneko/freebsd-vimage-jails/issues/2
brought the problem down to a double call of ng_node_name() before and
after a vnet move.  Because the name of the node is already known
(occupied by itself), the second call fails.

PR: 241954
Reported by:Paul Armstrong
MFC:1 week
Differential Revision: https://reviews.freebsd.org/D30110

 sys/netgraph/ng_base.c | 4 
 1 file changed, 4 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-26 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #4 from Ed Maste  ---
We should MFC this to stable branches also

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-26 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Takanori Watanabe  changed:

   What|Removed |Added

 Status|Open|Closed
 CC||takaw...@freebsd.org
 Resolution|--- |FIXED

--- Comment #3 from Takanori Watanabe  ---
Looks good, Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-26 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=14803ec8d193d8d46f4137a7dba61b277c6a2fed

commit 14803ec8d193d8d46f4137a7dba61b277c6a2fed
Author: Takanori Watanabe 
AuthorDate: 2021-05-26 09:23:33 +
Commit: Takanori Watanabe 
CommitDate: 2021-05-26 09:23:33 +

Fix a use-after-free in an error case.

PR: 255872
Submitted by:  lylgood
Differential Revision:  https://reviews.freebsd.org/D30454

 sys/netgraph/bluetooth/hci/ng_hci_evnt.c | 1 +
 1 file changed, 1 insertion(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-25 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Kubilay Kocak  changed:

   What|Removed |Added

URL||https://reviews.freebsd.org
   ||/D30454
  Flags||mfc-stable13?,
   ||mfc-stable12?,
   ||mfc-stable11?
   Keywords||needs-qa
Summary|[PATCH] |netgraph/bluetooth/hci: Fix
   |netgraph/bluetooth/hci: Fix |a use after free in
   |a use after free in |le_connection_complete
   |le_connection_complete  |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] [PATCH] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-25 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||n...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255872] [PATCH] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-25 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Open
   Assignee|n...@freebsd.org |ma...@freebsd.org

--- Comment #1 from Mark Johnston  ---
https://reviews.freebsd.org/D30454

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 255874] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable13+,
   ||mfc-stable12+,
   ||mfc-stable11+
URL||https://reviews.freebsd.org
   ||/D30273
Summary|[PATCH] netgraph: Fix a |netgraph: Fix a double free
   |double free in  |in ng_checksum_rcvdata
   |ng_checksum_rcvdata |
   Keywords|patch   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=6bc3535519f7206f844c3ffd0ee282e8875dceb4

commit 6bc3535519f7206f844c3ffd0ee282e8875dceb4
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-15 09:32:57 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-23 13:01:34 +

netgraph/ng_checksum: Fix double free error

m_pullup(9) frees the mbuf(9) chain in the case of an allocation error.
The mbuf chain must not be freed again in this case.

PR: 255874
Submitted by:   
Approved by:markj
Differential Revision: https://reviews.freebsd.org/D30273

(cherry picked from commit 687e510e5ce32fddf46a9dc1d517ccc8a8e25581)

 sys/netgraph/ng_checksum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=76b96a4ec7fa8cffbfe8e876d622fd4e69f25267

commit 76b96a4ec7fa8cffbfe8e876d622fd4e69f25267
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-15 09:32:57 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-23 12:59:28 +

netgraph/ng_checksum: Fix double free error

m_pullup(9) frees the mbuf(9) chain in the case of an allocation error.
The mbuf chain must not be freed again in this case.

PR: 255874
Submitted by:   
Approved by:markj
Differential Revision: https://reviews.freebsd.org/D30273

(cherry picked from commit 687e510e5ce32fddf46a9dc1d517ccc8a8e25581)

 sys/netgraph/ng_checksum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

--- Comment #3 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=fa670efa25ad960e17a6a9cb4601e5c3f19de5da

commit fa670efa25ad960e17a6a9cb4601e5c3f19de5da
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-15 09:32:57 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-23 12:55:20 +

netgraph/ng_checksum: Fix double free error

m_pullup(9) frees the mbuf(9) chain in the case of an allocation error.
The mbuf chain must not be freed again in this case.

PR: 255874
Submitted by:   
Approved by:markj
Differential Revision: https://reviews.freebsd.org/D30273

(cherry picked from commit 687e510e5ce32fddf46a9dc1d517ccc8a8e25581)

 sys/netgraph/ng_checksum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

Lutz Donnerhacke  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=687e510e5ce32fddf46a9dc1d517ccc8a8e25581

commit 687e510e5ce32fddf46a9dc1d517ccc8a8e25581
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-15 09:32:57 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-16 17:39:51 +

netgraph/ng_checksum: Fix double free error

m_pullup(9) frees the mbuf(9) chain in the case of an allocation error.
The mbuf chain must not be freed again in this case.

PR: 255874
Submitted by:   
Approved by:markj
MFC after:  1 week
Differential Revision: https://reviews.freebsd.org/D30273

 sys/netgraph/ng_checksum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 246706] [netgraph] kernel panic due to corrupted memory

2021-05-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246706

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|New |Open

--- Comment #1 from Lutz Donnerhacke  ---
Do not let mpd5 delete the interfaces directly.

This causes a lot of trouble, so I decided to patch the mpd to delay the
destruction of interfaces as long as possible (or reused them, if needed). This
patch made my mpd installation rock stable.

https://lutz.donnerhacke.de/Blog/Neues-vom-Speicherfresser

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #1 from Lutz Donnerhacke  ---
Thank you for you detection, analysis and fix of this bug.

Change is now under review D30273
I'll wait for someone else to review this independently.
If your bug report had been a review, I'v simply accepted it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|New |Open
   Keywords||patch
 CC||n...@freebsd.org
   Assignee|n...@freebsd.org |don...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 255874] [PATCH] netgraph: Fix a double free in ng_checksum_rcvdata

2021-05-14 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255874

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 255872] [PATCH] netgraph/bluetooth/hci: Fix a use after free in le_connection_complete

2021-05-14 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255872

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 187835] ngctl(8) strange behavior when adding more than 530 vlan through netgraph

2021-05-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187835

--- Comment #20 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=2b3074de33533f2703707c9b1c5e50a98621fdd1

commit 2b3074de33533f2703707c9b1c5e50a98621fdd1
Author: Lutz Donnerhacke 
AuthorDate: 2021-02-07 21:07:34 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-09 13:25:05 +

netgraph/ng_base: Allow larger BINARY2ASCII conversions

Allocate the necessary memory for the conversion dynamically starting
with a value which is sufficient for almost all normal cases.

PR: 187835
Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D23840

(cherry picked from commit 45d75e3ac3fb5bf8230ca28dc09b48c6e5ed7a4f)

 sys/netgraph/ng_base.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 187835] ngctl(8) strange behavior when adding more than 530 vlan through netgraph

2021-05-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187835

--- Comment #19 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=e1caa707fee06d00a0e6ba0445d734e748721d77

commit e1caa707fee06d00a0e6ba0445d734e748721d77
Author: Lutz Donnerhacke 
AuthorDate: 2021-02-07 21:07:34 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-09 13:23:19 +

netgraph/ng_base: Allow larger BINARY2ASCII conversions

Allocate the necessary memory for the conversion dynamically starting
with a value which is sufficient for almost all normal cases.

PR: 187835
Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D23840

(cherry picked from commit 45d75e3ac3fb5bf8230ca28dc09b48c6e5ed7a4f)

 sys/netgraph/ng_base.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 187835] ngctl(8) strange behavior when adding more than 530 vlan through netgraph

2021-05-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187835

--- Comment #18 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=0d8ba15a0e9dbb5928d0fd89011417b707f7a366

commit 0d8ba15a0e9dbb5928d0fd89011417b707f7a366
Author: Lutz Donnerhacke 
AuthorDate: 2021-02-07 21:07:34 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-05-09 13:20:48 +

netgraph/ng_base: Allow larger BINARY2ASCII conversions

Allocate the necessary memory for the conversion dynamically starting
with a value which is sufficient for almost all normal cases.

PR: 187835
Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D23840

(cherry picked from commit 45d75e3ac3fb5bf8230ca28dc09b48c6e5ed7a4f)

 sys/netgraph/ng_base.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241954] netgraph fails on concurrent node rename

2021-05-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #3 from Lutz Donnerhacke  ---
Please test this patch: https://reviews.freebsd.org/D30110

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241954] netgraph fails on concurrent node rename

2021-05-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #2 from Lutz Donnerhacke  ---
https://github.com/genneko/freebsd-vimage-jails/issues/2 describes the problem
in detail: ng_name_node() is called twice and does not recognize the rename to
the identical name. This might be solvable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241954] netgraph fails on concurrent node rename

2021-05-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|New |Open
 CC||n...@freebsd.org
   Assignee|n...@freebsd.org |don...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 243833] netgraph: If queue is full, don't enqueue in ng_source_rcvdata()

2021-03-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243833

Neel Chauhan  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241954] netgraph fails on concurrent node rename

2021-03-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954

--- Comment #1 from Kurt Jaeger  ---
See also:

https://github.com/genneko/freebsd-vimage-jails/issues/2

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 243829] netgraph: Add RFC 6598/Carrier Grade NAT support to ng_nat

2021-03-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243829

Neel Chauhan  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #1 from Neel Chauhan  ---
Has already been committed by donner@.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 240530] netgraph/ng_source: Allow ng_source to inject into any netgraph network

2021-02-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240530

--- Comment #3 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=591e21210e35b7b0ed0a8c39404e15a1225976bf

commit 591e21210e35b7b0ed0a8c39404e15a1225976bf
Author: Lutz Donnerhacke 
AuthorDate: 2021-01-17 20:35:28 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-02-16 08:25:59 +

netgraph/ng_source: Allow ng_source to inject into any netgraph network

PR: 240530
Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D21968

(cherry picked from commit 75e7ef74dfc12e01b1ef4706110d238639e04543)

 share/man/man4/ng_source.4 | 11 +--
 sys/netgraph/ng_source.c   |  4 ++--
 2 files changed, 11 insertions(+), 4 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 187835] ngctl(8) strange behavior when adding more than 530 vlan through netgraph

2021-02-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187835

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 187835] ngctl(8) strange behavior when adding more than 530 vlan through netgraph

2021-02-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187835

--- Comment #17 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=45d75e3ac3fb5bf8230ca28dc09b48c6e5ed7a4f

commit 45d75e3ac3fb5bf8230ca28dc09b48c6e5ed7a4f
Author: Lutz Donnerhacke 
AuthorDate: 2021-02-07 21:07:34 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-02-08 13:31:58 +

netgraph/ng_base: Allow larger BINARY2ASCII conversions

Allocate the necessary memory for the conversion dynamically starting
with a value which is sufficient for almost all normal cases.

PR: 187835
Reviewed by:kp
Differential Revision: https://reviews.freebsd.org/D23840

 sys/netgraph/ng_base.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netgraph with ng_netflow and ng_gridge nodes

2021-02-06 Thread petru garstea


If you like to understand your network, try:
# ngctl dot [-c]
and paste the output to http://www.webgraphviz.com/


I used it when was building the graph :)

On 2/6/21 11:48 AM, Lutz Donnerhacke wrote:

On Sat, Feb 06, 2021 at 11:10:29AM -0500, petru garstea wrote:

Greetings,

I have come up with a graph with no use of ng_tee, ng_hub or ng_one2many.

Also I validated the flows on a collector

In case anybody has the same use case I am sharing the graph

mkpeer re0: netflow lower iface0
name re0:lower netflow
connect re0: netflow: upper out1
mkpeer netflow: bridge out0 link0
name netflow:out0 re0bridge
connect re0bridge: netflow: link1 iface1
mkpeer re0bridge: eiface link2 ether
name re0bridge:link2 ng0
mkpeer netflow: ksocket export9 inet/dgram/udp
msg re0: setpromisc 1
msg re0: setautosrc 0
msg netflow: setconfig {iface=0 conf=11}
msg netflow: setconfig {iface=1 conf=11}
msg netflow:export9 connect inet/${collector_ip}:${port}


bridge.link0 - out0.netflow.iface0 --- lower.re0
  \.link1 --- iface1./ \.out1 - upper./
  \.link2 - ether.ng0

So you collect the data from the outside world to the re0 interface (IP
stack) twice, but you can catch the data from the ng0 interface to re0
separate from the data to outside.

If this is your desired setup, fine.

If you like to understand your network, try:
# ngctl dot [-c]
and paste the output to http://www.webgraphviz.com/

HTH

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netgraph with ng_netflow and ng_gridge nodes

2021-02-06 Thread petru garstea


Greetings,

I have come up with a graph with no use of ng_tee, ng_hub or ng_one2many.

Also I validated the flows on a collector

In case anybody has the same use case I am sharing the graph

mkpeer re0: netflow lower iface0
name re0:lower netflow
connect re0: netflow: upper out1
mkpeer netflow: bridge out0 link0
name netflow:out0 re0bridge
connect re0bridge: netflow: link1 iface1
mkpeer re0bridge: eiface link2 ether
name re0bridge:link2 ng0
mkpeer netflow: ksocket export9 inet/dgram/udp
msg re0: setpromisc 1
msg re0: setautosrc 0
msg netflow: setconfig {iface=0 conf=11}
msg netflow: setconfig {iface=1 conf=11}
msg netflow:export9 connect inet/${collector_ip}:${port}

Cheers,

Petru Garstea

On 2/2/21 3:26 PM, Lutz Donnerhacke wrote:

On Tue, Feb 02, 2021 at 09:16:49PM +0100, Lutz Donnerhacke wrote:

fxp0.lower -- iface0.netgraph.out0 -- link1.bridge.link2 -- upper.fxp0
  \.link3 -- ether.eiface

The strange thing is, that both fxp0 and eiface provide an interface to the
kernel IP stack. This is confusing (for the kernel).

I'd like to point you to ng_tee instead of ng_bridge for a read only access
to the communitcation (depending on the direction). Even ng_one2many or
ng_hub might be a better solution.

If you only need the eiface to attach tcpdump, you can omit it completely,
because tcpdump is able to sniff on the fxp0 even if the netgraph hooks are
set.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netgraph with ng_netflow and ng_gridge nodes

2021-02-06 Thread Lutz Donnerhacke

On Sat, Feb 06, 2021 at 11:10:29AM -0500, petru garstea wrote:
> Greetings,
>
> I have come up with a graph with no use of ng_tee, ng_hub or ng_one2many.
>
> Also I validated the flows on a collector
>
> In case anybody has the same use case I am sharing the graph
>
> mkpeer re0: netflow lower iface0
> name re0:lower netflow
> connect re0: netflow: upper out1
> mkpeer netflow: bridge out0 link0
> name netflow:out0 re0bridge
> connect re0bridge: netflow: link1 iface1
> mkpeer re0bridge: eiface link2 ether
> name re0bridge:link2 ng0
> mkpeer netflow: ksocket export9 inet/dgram/udp
> msg re0: setpromisc 1
> msg re0: setautosrc 0
> msg netflow: setconfig {iface=0 conf=11}
> msg netflow: setconfig {iface=1 conf=11}
> msg netflow:export9 connect inet/${collector_ip}:${port}


bridge.link0 - out0.netflow.iface0 --- lower.re0
 \.link1 --- iface1./ \.out1 - upper./
 \.link2 - ether.ng0

So you collect the data from the outside world to the re0 interface (IP
stack) twice, but you can catch the data from the ng0 interface to re0
separate from the data to outside.

If this is your desired setup, fine.

If you like to understand your network, try:
# ngctl dot [-c]
and paste the output to http://www.webgraphviz.com/

HTH
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 240685] netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type)

2021-02-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240685

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #7 from Lutz Donnerhacke  ---
Node is now part of the system.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netgraph with ng_netflow and ng_gridge nodes

2021-02-02 Thread Lutz Donnerhacke

On Tue, Feb 02, 2021 at 09:16:49PM +0100, Lutz Donnerhacke wrote:
> fxp0.lower -- iface0.netgraph.out0 -- link1.bridge.link2 -- upper.fxp0
>  \.link3 -- ether.eiface

The strange thing is, that both fxp0 and eiface provide an interface to the
kernel IP stack. This is confusing (for the kernel).

I'd like to point you to ng_tee instead of ng_bridge for a read only access
to the communitcation (depending on the direction). Even ng_one2many or
ng_hub might be a better solution.

If you only need the eiface to attach tcpdump, you can omit it completely,
because tcpdump is able to sniff on the fxp0 even if the netgraph hooks are
set.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netgraph with ng_netflow and ng_gridge nodes

2021-02-02 Thread Lutz Donnerhacke

On Tue, Feb 02, 2021 at 10:05:15AM -0500, petru garstea wrote:
> Hi,
>
> I need help to unify 2 netgraphs
>
> 1st ng_bridge netgraph
>
> ngctl mkpeer fxp0: bridge lower link0
> ngctl connect fxp0: em0:lower upper link1
> ngctl name fxp0:lower em0Bridge
> ngctl mkpeer fxp0:lower eiface link3 ether

So you tap the fxp0 with a bridge and attach an virtual interface.

> 2nd ng_netflow netgraph
>
> mkpeer fxp0: netflow  lower iface0
> name fxp0:lower netflow
> connect fxp0: netflow: upper  out0
> mkpeer netflow: ksocket export inet/dgram/udp
> msg netflow:export connect inet/10.0.0.1:

So you inject a bidirectional netflow analyser into the fxp0 interface.

> I cannot run both graphs at the same time because both of them are trying to 
> use fxp0 interface lower and upper hooks.
> I believe it is necessary to introduce an extra node but I am not sure.

You need to define which communication you want to analyse with netflow.

I.e. you want to analyze the traffic on the wire:

fxp0.lower -- iface0.netgraph.out0 -- link1.bridge.link2 -- upper.fxp0
 \.link3 -- ether.eiface

This will exclude the traffic between the eiface and the fxp0 IP-stack.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

netgraph with ng_netflow and ng_gridge nodes

2021-02-02 Thread petru garstea


Hi,

I need help to unify 2 netgraphs

1st ng_bridge netgraph

ngctl mkpeer fxp0: bridge lower link0
ngctl connect fxp0: em0:lower upper link1
ngctl name fxp0:lower em0Bridge
ngctl mkpeer fxp0:lower eiface link3 ether

2nd ng_netflow netgraph

mkpeer fxp0: netflowlower iface0
name fxp0:lower netflow
connect fxp0: netflow: upperout0
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow:export connect inet/10.0.0.1:


I cannot run both graphs at the same time because both of them are trying to 
use fxp0 interface lower and upper hooks.
I believe it is necessary to introduce an extra node but I am not sure.

Please advise

Cheers,
Petru

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241462] netgraph/ng_tag: Variable length data can not be set for all length

2021-02-01 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241462

--- Comment #3 from commit-h...@freebsd.org ---
A commit in branch stable/11 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=90d158c0cf2598fde2ea1c7cd58909cf5a21c471

commit 90d158c0cf2598fde2ea1c7cd58909cf5a21c471
Author: Lutz Donnerhacke 
AuthorDate: 2021-01-02 13:58:17 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-02-01 14:07:31 +

netgraph/ng_tag: permit variable length data

ng_tag(4) operate on arbitrary data of mbuf_tags(9).  Those structures
are padded to the next multiple of the alignment by the compiler.
Hence a valid argument has be at most as long as the data received.

PR: 241462
Reviewed by:kp
Approved by:philip (mentor)
Differential Revision: https://reviews.freebsd.org/D22140

(cherry picked from commit 7c7c231c14246a709270bf3f3a4593208e84d01a)

 sys/netgraph/ng_tag.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 241462] netgraph/ng_tag: Variable length data can not be set for all length

2021-02-01 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241462

--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=305b3ca5f40cbfff1e29f7e2e10a636331a8575c

commit 305b3ca5f40cbfff1e29f7e2e10a636331a8575c
Author: Lutz Donnerhacke 
AuthorDate: 2021-01-02 13:58:17 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-02-01 13:55:42 +

netgraph/ng_tag: permit variable length data

ng_tag(4) operate on arbitrary data of mbuf_tags(9).  Those structures
are padded to the next multiple of the alignment by the compiler.
Hence a valid argument has be at most as long as the data received.

PR: 241462
Reviewed by:kp
Approved by:philip (mentor)
Differential Revision: https://reviews.freebsd.org/D22140

(cherry picked from commit 7c7c231c14246a709270bf3f3a4593208e84d01a)

 sys/netgraph/ng_tag.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249327] fix IP address parsing in netgraph eating too many characters

2020-10-31 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249327

Kubilay Kocak  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
   Keywords||needs-qa
URL||https://reviews.freebsd.org
   ||/D26489
  Flags||mfc-stable12?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249327] fix IP address parsing in netgraph eating too many characters

2020-10-31 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249327

Bjoern A. Zeeb  changed:

   What|Removed |Added

 Status|New |Open

--- Comment #3 from Bjoern A. Zeeb  ---
I added #network to the review so that a committer might also have a look and
deal with this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249327] fix IP address parsing in netgraph eating too many characters

2020-10-31 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249327

--- Comment #2 from Markus Stoff  ---
The proposed fix has been approved in review D26489.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Getting netgraph stats

2020-10-23 Thread Paul Thornton


I am having a problem monitoring network stats on jails on a host.

Scenario:
One host, FreeBSD 12.1, with a small number of vnet jails.

I'm using netgraph to bridge two or more VLANs from physical NICs into 
each jail - so each jail has at least 2 ngether interfaces which are the 
only NICs in the jail.


All of this works well.

And then I wanted to see what each of my ngethX interface statistics 
were doing - from my host.  snmpd only sees the physical NICs (of 
course, because the ngeth ones don't appear any more since the jails are 
started - they all moved to the jails).


As another approach, is there any way for me to get the network stats 
(in/out packets and in/out bytes) from my ngeth netgraph nodes directly?


Or have I missed some other way?  I really need to monitor the jails 
from the outside as I cannot guarantee I can reach snmpd running inside 
the jail (think of the jail as being a private environment where I 
cannot route my SNMP requests to).


Thanks

Paul.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249327] fix IP address parsing in netgraph eating too many characters

2020-09-20 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249327

--- Comment #1 from Markus Stoff  ---
See also review D26489.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249327] fix IP address parsing in netgraph eating too many characters

2020-09-15 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249327

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org
Summary|IP address parsing in   |fix IP address parsing in
   |netgraph eats to many   |netgraph eating too many
   |characters  |characters

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249275] New netgraph nodetype: ng_antispoof

2020-09-14 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249275

Markus Stoff  changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|New |Closed

--- Comment #2 from Markus Stoff  ---
The proposed functionality is already provided by ng_bpf(4).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249275] New netgraph nodetype: ng_antispoof

2020-09-13 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249275

--- Comment #1 from Markus Stoff  ---
Please let me also have your thoughts at review D26420.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 249275] New netgraph nodetype: ng_antispoof

2020-09-12 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249275

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Reviewing two IPFW/netgraph/natd patches (RFC 6598/Carrier Grade NAT)

2020-07-05 Thread Adrian Chadd

hi!

On Fri, 3 Jul 2020 at 20:12, Neel Chauhan  wrote:

> Hi freebsd-hackers@, freebsd-net@,
>
> These two patches that will be described are a continuation of r357092.
>
> r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
> 100.64.0.0/10) in libalias and IPFW in-kernel NAT.
>
> These two patches add support for RFC 6598 to natd and ng_nat
> respectively:
>
>   * natd CGN patch: https://reviews.freebsd.org/D23356
>   * ng_nat CGN patch: https://reviews.freebsd.org/D23461
>
> Currently, CGN support is missing from natd and ng_nat.
>
> Could someone please review and/or commit these patches?
>

I'm happy to commit these if noone complains too much to me about it.

I approved one of them. I'll go approve the other now.



-adrian


>
> Best,
>
> Neel Chauhan
>
> ===
>
> https://www.neelc.org/
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reviewing two IPFW/netgraph/natd patches (RFC 6598/Carrier Grade NAT)

2020-07-03 Thread Neel Chauhan


Hi freebsd-hackers@, freebsd-net@,

These two patches that will be described are a continuation of r357092.

r357092 added support for RFC 6598/Carrier Grade NAT (subnet: 
100.64.0.0/10) in libalias and IPFW in-kernel NAT.


These two patches add support for RFC 6598 to natd and ng_nat 
respectively:


 * natd CGN patch: https://reviews.freebsd.org/D23356
 * ng_nat CGN patch: https://reviews.freebsd.org/D23461

Currently, CGN support is missing from natd and ng_nat.

Could someone please review and/or commit these patches?

Best,

Neel Chauhan

===

https://www.neelc.org/
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-09 Thread Eugene Grosbein

10.06.2020 6:48, John-Mark Gurney wrote:

> Tom Marcoen wrote this message on Tue, Jun 09, 2020 at 12:53 +0200:
>> That is what I had in mind. Though I was hoping I could put the encryption
>> in NetGraph too so that I would not see that interface on my host where I
>> do not need to see it.
> 
> You wouldn't see any interface if you're encrypting and authenticating
> a UDP tunnel with IPsec...  the Security Association (SA) is transparent
> and does not appear on the interface list of your host..

This is only partially true these days:
https://www.freebsd.org/cgi/man.cgi?query=if_ipsec

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-09 Thread John-Mark Gurney

Tom Marcoen wrote this message on Tue, Jun 09, 2020 at 12:53 +0200:
> That is what I had in mind. Though I was hoping I could put the encryption
> in NetGraph too so that I would not see that interface on my host where I
> do not need to see it.

You wouldn't see any interface if you're encrypting and authenticating
a UDP tunnel with IPsec...  the Security Association (SA) is transparent
and does not appear on the interface list of your host..

> On Tue, 9 Jun 2020 at 05:28, Julian Elischer  wrote:
> 
> > On 5/27/20 4:20 AM, Eugene Grosbein wrote:
> > > 27.05.2020 15:06, Tom Marcoen wrote:
> > >
> > >> Hey all,
> > >>
> > >> I'm new to this mailing list and also quite new to FreeBSD (huray,
> > welcome
> > >> to me!) so bare with me, please.
> > >>
> > >> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> > and
> > >> I was looking at some of the examples provided in
> > >> /usr/share/examples/netgraph and now have the following question.
> > >> The udp.tunnel example shows an iface point-to-point connection but it
> > is
> > >> unencrypted. Of course I could encrypt it with an IPsec tunnel on the
> > host
> > >> or tunnel it through SSH, but I was wondering whether there exists a
> > nice
> > >> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> > >> traffic on the inside hook and sending out encrypted traffic on the
> > outside
> > >> hook.
> > > There is ng_mppc(4) netgraph node capable to perform relatively weak
> > MPPE encryption
> > > (and/or compression) but it is designed to work with ng_ppp(4) node
> > encapsulating IP packets into PPP frames.
> > > I doubt it's very efficient for inter-jail traffic.
> > >
> > > Why do you need encryption for inter-jails traffic in first place?
> > > Encryption is needed for traffic passing untrusted channels where data
> > interception is possible
> > > but inter-jail traffic does not leave the kernel at all until it hits
> > destination jail.
> > Once you have a udp tunnel set up you just need to set up an IPSEC SA
> > to to encrypt just that tunnel.
> > It's not required to do the encryption in netgraph.
> > there is a script to make the tunnel in
> > /usr/share/examples.netgraph/udp.tunnel
> > you just need to set up the SA to catch it..
> > you can also if you desire you can also put a netgraph bridge at both
> > ends of the tunnel and have a single subnet connected by the link. The
> > bridge nodes are "learning" so they will learn when to send packets over
> > the link and when not to.
> > You can also play tricks with FIBs so that tunnel envelope packets and all
> > other packets use different routing tables.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-09 Thread Tom Marcoen

Hey Julian,

That is what I had in mind. Though I was hoping I could put the encryption
in NetGraph too so that I would not see that interface on my host where I
do not need to see it.

On Tue, 9 Jun 2020 at 05:28, Julian Elischer  wrote:

> On 5/27/20 4:20 AM, Eugene Grosbein wrote:
> > 27.05.2020 15:06, Tom Marcoen wrote:
> >
> >> Hey all,
> >>
> >> I'm new to this mailing list and also quite new to FreeBSD (huray,
> welcome
> >> to me!) so bare with me, please.
> >>
> >> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> and
> >> I was looking at some of the examples provided in
> >> /usr/share/examples/netgraph and now have the following question.
> >> The udp.tunnel example shows an iface point-to-point connection but it
> is
> >> unencrypted. Of course I could encrypt it with an IPsec tunnel on the
> host
> >> or tunnel it through SSH, but I was wondering whether there exists a
> nice
> >> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> >> traffic on the inside hook and sending out encrypted traffic on the
> outside
> >> hook.
> > There is ng_mppc(4) netgraph node capable to perform relatively weak
> MPPE encryption
> > (and/or compression) but it is designed to work with ng_ppp(4) node
> encapsulating IP packets into PPP frames.
> > I doubt it's very efficient for inter-jail traffic.
> >
> > Why do you need encryption for inter-jails traffic in first place?
> > Encryption is needed for traffic passing untrusted channels where data
> interception is possible
> > but inter-jail traffic does not leave the kernel at all until it hits
> destination jail.
> Once you have a udp tunnel set up you just need to set up an IPSEC SA
> to to encrypt just that tunnel.
> It's not required to do the encryption in netgraph.
> there is a script to make the tunnel in
> /usr/share/examples.netgraph/udp.tunnel
> you just need to set up the SA to catch it..
> you can also if you desire you can also put a netgraph bridge at both
> ends of the tunnel and have a single subnet connected by the link. The
> bridge nodes are "learning" so they will learn when to send packets over
> the link and when not to.
> You can also play tricks with FIBs so that tunnel envelope packets and all
> other packets use different routing tables.
>
>
> >
> > ___
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-08 Thread Julian Elischer


On 6/8/20 7:03 AM, Marko Zec wrote:

On Mon, 8 Jun 2020 15:36:42 +0200
Tom Marcoen  wrote:


Hey Jan,

I know about the vast performance improvements with if_bridge(4)
(Thank you, Kristof Provost), the problem with using it for jails is
that once you have a lot of jails, your hosts gets way too many epair
interfaces in its ifconfig, which I really do not like. So I would
prefer using Netgraph.

I don't understand why is everythin doing everything they can _not_
to use Netgraph?

Netgraph is very cool and underrated indeed.  A part of the problem
might be that people may find it easier to construct if_bridge
configurations, than to spend some time learning how to establish the
same functionality using netgraph, which requires a few more steps.  I
was one of such lazy persons myself...

But a more down-to-the-earth problem with ng_bridge may be that it is
single-threaded (look around line 319 in sys/netgraph/ng_bridge.c),
which most likely is going to make it less performant than if_bridge
(after recent improvements)

Since netgraph was written in 1996 it as required only one rework to
add some support for multi-threading so possibly after 24 years we
may need to change a few lines... :-)

On Mon, 8 Jun 2020 at 13:47, Jan Bramkamp  wrote:


On 27.05.20 10:06, Tom Marcoen wrote:

Hey all,

I'm new to this mailing list and also quite new to FreeBSD
(huray,

welcome

to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD
jails

and

I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection
but it is unencrypted. Of course I could encrypt it with an IPsec
tunnel on the

host

or tunnel it through SSH, but I was wondering whether there
exists a nice Netgraph solution, e.g. a node with two hooks,
receiving unencrypted traffic on the inside hook and sending out
encrypted traffic on the

outside

hook.

Netgraph is a very flexible tool, but not needed for this. First of
all if_bridge(4) just got a massive throughput gain by at least a
factor of 5 in 13-current and 12-stable. Next you would be
reinventing the wheel with ng_bridge and ng_ksocket to tunnel
ethernet in UDP. As soon as you have more than two jail hosts
you'll run into new problems.

The canonical solution to your problem is VXLAN. This allows you to
learn traffic to the unicast tunnel endpoint address for unicast
cast traffic and multicast the rest. These encapsulations have been
invented to allow emulate a shared layer 2 Ethernet networks per
tennant. Unless your jails are VNET enabled and your jail admins
require a shared layer 2 network you can avoid most of this
overhead with dynamic routing. I know this sounds a lot like
"your're holding it wrong". Your approach would work, but it would
cripple performance unless you can wait for FreeBSD 12.2 and switch
from netgraph to if_bridge(4). Routing is fast (enough) in the
existing FreeBSD releases and in my opinion the cleaner solution,
but it complicates hosting services expecting a shared layer 2 e.g.
mDNS and DLNA require either multicast routing or proxies.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-08 Thread Julian Elischer


On 5/27/20 4:20 AM, Eugene Grosbein wrote:

27.05.2020 15:06, Tom Marcoen wrote:


Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and
I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.

There is ng_mppc(4) netgraph node capable to perform relatively weak MPPE 
encryption
(and/or compression) but it is designed to work with ng_ppp(4) node 
encapsulating IP packets into PPP frames.
I doubt it's very efficient for inter-jail traffic.

Why do you need encryption for inter-jails traffic in first place?
Encryption is needed for traffic passing untrusted channels where data 
interception is possible
but inter-jail traffic does not leave the kernel at all until it hits 
destination jail.
Once you have a udp tunnel set up you just need to set up an IPSEC SA 
to to encrypt just that tunnel.

It's not required to do the encryption in netgraph.
there is a script to make the tunnel in 
/usr/share/examples.netgraph/udp.tunnel

you just need to set up the SA to catch it..
you can also if you desire you can also put a netgraph bridge at both
ends of the tunnel and have a single subnet connected by the link. The
bridge nodes are "learning" so they will learn when to send packets over
the link and when not to.
You can also play tricks with FIBs so that tunnel envelope packets and all
other packets use different routing tables.




___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-08 Thread Marko Zec

On Mon, 8 Jun 2020 15:36:42 +0200
Tom Marcoen  wrote:

> Hey Jan,
> 
> I know about the vast performance improvements with if_bridge(4)
> (Thank you, Kristof Provost), the problem with using it for jails is
> that once you have a lot of jails, your hosts gets way too many epair
> interfaces in its ifconfig, which I really do not like. So I would
> prefer using Netgraph.
> 
> I don't understand why is everythin doing everything they can _not_
> to use Netgraph?

Netgraph is very cool and underrated indeed.  A part of the problem
might be that people may find it easier to construct if_bridge
configurations, than to spend some time learning how to establish the
same functionality using netgraph, which requires a few more steps.  I
was one of such lazy persons myself...

But a more down-to-the-earth problem with ng_bridge may be that it is
single-threaded (look around line 319 in sys/netgraph/ng_bridge.c),
which most likely is going to make it less performant than if_bridge
(after recent improvements)

> 
> On Mon, 8 Jun 2020 at 13:47, Jan Bramkamp  wrote:
> 
> > On 27.05.20 10:06, Tom Marcoen wrote:  
> > > Hey all,
> > >
> > > I'm new to this mailing list and also quite new to FreeBSD
> > > (huray,  
> > welcome  
> > > to me!) so bare with me, please.
> > >
> > > I'm reading up on Netgraph on how I can integrate it with FreeBSD
> > > jails  
> > and  
> > > I was looking at some of the examples provided in
> > > /usr/share/examples/netgraph and now have the following question.
> > > The udp.tunnel example shows an iface point-to-point connection
> > > but it is unencrypted. Of course I could encrypt it with an IPsec
> > > tunnel on the  
> > host  
> > > or tunnel it through SSH, but I was wondering whether there
> > > exists a nice Netgraph solution, e.g. a node with two hooks,
> > > receiving unencrypted traffic on the inside hook and sending out
> > > encrypted traffic on the  
> > outside  
> > > hook.  
> >
> > Netgraph is a very flexible tool, but not needed for this. First of
> > all if_bridge(4) just got a massive throughput gain by at least a
> > factor of 5 in 13-current and 12-stable. Next you would be
> > reinventing the wheel with ng_bridge and ng_ksocket to tunnel
> > ethernet in UDP. As soon as you have more than two jail hosts
> > you'll run into new problems.
> >
> > The canonical solution to your problem is VXLAN. This allows you to
> > learn traffic to the unicast tunnel endpoint address for unicast
> > cast traffic and multicast the rest. These encapsulations have been
> > invented to allow emulate a shared layer 2 Ethernet networks per
> > tennant. Unless your jails are VNET enabled and your jail admins
> > require a shared layer 2 network you can avoid most of this
> > overhead with dynamic routing. I know this sounds a lot like
> > "your're holding it wrong". Your approach would work, but it would
> > cripple performance unless you can wait for FreeBSD 12.2 and switch
> > from netgraph to if_bridge(4). Routing is fast (enough) in the
> > existing FreeBSD releases and in my opinion the cleaner solution,
> > but it complicates hosting services expecting a shared layer 2 e.g.
> > mDNS and DLNA require either multicast routing or proxies.
> >
> > ___
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to
> > "freebsd-net-unsubscr...@freebsd.org" 
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-08 Thread Tom Marcoen

Hey Jan,

I know about the vast performance improvements with if_bridge(4) (Thank
you, Kristof Provost), the problem with using it for jails is that once you
have a lot of jails, your hosts gets way too many epair interfaces in its
ifconfig, which I really do not like. So I would prefer using Netgraph.

I don't understand why is everythin doing everything they can _not_ to use
Netgraph?

On Mon, 8 Jun 2020 at 13:47, Jan Bramkamp  wrote:

> On 27.05.20 10:06, Tom Marcoen wrote:
> > Hey all,
> >
> > I'm new to this mailing list and also quite new to FreeBSD (huray,
> welcome
> > to me!) so bare with me, please.
> >
> > I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> and
> > I was looking at some of the examples provided in
> > /usr/share/examples/netgraph and now have the following question.
> > The udp.tunnel example shows an iface point-to-point connection but it is
> > unencrypted. Of course I could encrypt it with an IPsec tunnel on the
> host
> > or tunnel it through SSH, but I was wondering whether there exists a nice
> > Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> > traffic on the inside hook and sending out encrypted traffic on the
> outside
> > hook.
>
> Netgraph is a very flexible tool, but not needed for this. First of all
> if_bridge(4) just got a massive throughput gain by at least a factor of
> 5 in 13-current and 12-stable. Next you would be reinventing the wheel
> with ng_bridge and ng_ksocket to tunnel ethernet in UDP. As soon as you
> have more than two jail hosts you'll run into new problems.
>
> The canonical solution to your problem is VXLAN. This allows you to
> learn traffic to the unicast tunnel endpoint address for unicast cast
> traffic and multicast the rest. These encapsulations have been invented
> to allow emulate a shared layer 2 Ethernet networks per tennant. Unless
> your jails are VNET enabled and your jail admins require a shared layer
> 2 network you can avoid most of this overhead with dynamic routing. I
> know this sounds a lot like "your're holding it wrong". Your approach
> would work, but it would cripple performance unless you can wait for
> FreeBSD 12.2 and switch from netgraph to if_bridge(4). Routing is fast
> (enough) in the existing FreeBSD releases and in my opinion the cleaner
> solution, but it complicates hosting services expecting a shared layer 2
> e.g. mDNS and DLNA require either multicast routing or proxies.
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-08 Thread Jan Bramkamp


On 27.05.20 10:06, Tom Marcoen wrote:

Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and
I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.


Netgraph is a very flexible tool, but not needed for this. First of all 
if_bridge(4) just got a massive throughput gain by at least a factor of 
5 in 13-current and 12-stable. Next you would be reinventing the wheel 
with ng_bridge and ng_ksocket to tunnel ethernet in UDP. As soon as you 
have more than two jail hosts you'll run into new problems.


The canonical solution to your problem is VXLAN. This allows you to 
learn traffic to the unicast tunnel endpoint address for unicast cast 
traffic and multicast the rest. These encapsulations have been invented 
to allow emulate a shared layer 2 Ethernet networks per tennant. Unless 
your jails are VNET enabled and your jail admins require a shared layer 
2 network you can avoid most of this overhead with dynamic routing. I 
know this sounds a lot like "your're holding it wrong". Your approach 
would work, but it would cripple performance unless you can wait for 
FreeBSD 12.2 and switch from netgraph to if_bridge(4). Routing is fast 
(enough) in the existing FreeBSD releases and in my opinion the cleaner 
solution, but it complicates hosting services expecting a shared layer 2 
e.g. mDNS and DLNA require either multicast routing or proxies.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-07 Thread John-Mark Gurney

Tom Marcoen wrote this message on Fri, Jun 05, 2020 at 22:07 +0200:
> I'm sure I can come up with those ten-or-so lines myself. I was just hoping
> I could use a Netgraph node which performs the encryption before sending it
> through the ksocket node. Perhaps I should write such a node then.

There are LOTS of things you have to be careful about when writing
code to do this..  Key renegotiation after period of time, replay
preventation, authentication, etc...  It's not an easy task...

Using IPSEC would make a lot more sense...

> On Fri, 5 Jun 2020 at 22:04, Julian Elischer  wrote:
> 
> > On 6/5/20 12:13 PM, Tom Marcoen wrote:
> > > Hey Eugen,
> > >
> > > For some reason I did not receive your email. But I found your reply in
> > the
> > > archives.
> > >
> > > Anyway, the goal is to have two computers, each with a Netgraph bridge
> > node
> > > and jails connecting to these bridges. I want to connect both bridges
> > over
> > > the Internet securely. Using a UDP tunnel and encrypting that with IPsec
> > or
> > > wireguard or  would be an option, but it would be nicer if I could
> > use
> > > a Netgraph-native option.
> >
> >
> > In years past I used netgraph ksocket nodes to generate a udp tunnel
> > and then set up IPSEC to encrypt it.
> >
> > can be done from the command line with about 10 lines from memory.
> >
> > Unfortunately I don't have those 10 line at hand as it was at
> > JOB[current - 5]
> >
> > Julian
> >
> >
> > > Regards,
> > > Tom
> > >
> > > On Wed, 27 May 2020 at 10:06, Tom Marcoen  wrote:
> > >
> > >> Hey all,
> > >>
> > >> I'm new to this mailing list and also quite new to FreeBSD (huray,
> > welcome
> > >> to me!) so bare with me, please.
> > >>
> > >> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> > >> and I was looking at some of the examples provided in
> > >> /usr/share/examples/netgraph and now have the following question.
> > >> The udp.tunnel example shows an iface point-to-point connection but it
> > is
> > >> unencrypted. Of course I could encrypt it with an IPsec tunnel on the
> > host
> > >> or tunnel it through SSH, but I was wondering whether there exists a
> > nice
> > >> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> > >> traffic on the inside hook and sending out encrypted traffic on the
> > outside
> > >> hook.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-05 Thread Eugene Grosbein

06.06.2020 2:13, Tom Marcoen wrote:

> Hey Eugen,
> 
> For some reason I did not receive your email. But I found your reply in the
> archives.

Just look at your gmail spam folder. Gmail's antispam policy in not quite 
adequate.

> Anyway, the goal is to have two computers, each with a Netgraph bridge node
> and jails connecting to these bridges. I want to connect both bridges over
> the Internet securely. Using a UDP tunnel and encrypting that with IPsec or
> wireguard or  would be an option, but it would be nicer if I could use
> a Netgraph-native option.

Just create ordinary gif(4) or gre(4) tunnel between your two hosts and encrypt 
it with IPSec,
that will me more secure and much easier same time. Or, if you don't like 
gif/gre,
you maybe would like to use if_ipsec(4) native encapsulation for IPSec.
These *are* native options for FreeBSD. No reason to use more complex NETGRAPH 
schemes.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-05 Thread Tom Marcoen

I'm sure I can come up with those ten-or-so lines myself. I was just hoping
I could use a Netgraph node which performs the encryption before sending it
through the ksocket node. Perhaps I should write such a node then.

On Fri, 5 Jun 2020 at 22:04, Julian Elischer  wrote:

> On 6/5/20 12:13 PM, Tom Marcoen wrote:
> > Hey Eugen,
> >
> > For some reason I did not receive your email. But I found your reply in
> the
> > archives.
> >
> > Anyway, the goal is to have two computers, each with a Netgraph bridge
> node
> > and jails connecting to these bridges. I want to connect both bridges
> over
> > the Internet securely. Using a UDP tunnel and encrypting that with IPsec
> or
> > wireguard or .... would be an option, but it would be nicer if I could
> use
> > a Netgraph-native option.
>
>
> In years past I used netgraph ksocket nodes to generate a udp tunnel
> and then set up IPSEC to encrypt it.
>
> can be done from the command line with about 10 lines from memory.
>
> Unfortunately I don't have those 10 line at hand as it was at
> JOB[current - 5]
>
> Julian
>
>
> > Regards,
> > Tom
> >
> > On Wed, 27 May 2020 at 10:06, Tom Marcoen  wrote:
> >
> >> Hey all,
> >>
> >> I'm new to this mailing list and also quite new to FreeBSD (huray,
> welcome
> >> to me!) so bare with me, please.
> >>
> >> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> >> and I was looking at some of the examples provided in
> >> /usr/share/examples/netgraph and now have the following question.
> >> The udp.tunnel example shows an iface point-to-point connection but it
> is
> >> unencrypted. Of course I could encrypt it with an IPsec tunnel on the
> host
> >> or tunnel it through SSH, but I was wondering whether there exists a
> nice
> >> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> >> traffic on the inside hook and sending out encrypted traffic on the
> outside
> >> hook.
> >>
> >> Regards,
> >> Tom
> >>
> > ___
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-05 Thread Julian Elischer


On 6/5/20 12:13 PM, Tom Marcoen wrote:

Hey Eugen,

For some reason I did not receive your email. But I found your reply in the
archives.

Anyway, the goal is to have two computers, each with a Netgraph bridge node
and jails connecting to these bridges. I want to connect both bridges over
the Internet securely. Using a UDP tunnel and encrypting that with IPsec or
wireguard or  would be an option, but it would be nicer if I could use
a Netgraph-native option.



In years past I used netgraph ksocket nodes to generate a udp tunnel 
and then set up IPSEC to encrypt it.


can be done from the command line with about 10 lines from memory.

Unfortunately I don't have those 10 line at hand as it was at 
JOB[current - 5]


Julian



Regards,
Tom

On Wed, 27 May 2020 at 10:06, Tom Marcoen  wrote:


Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
and I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.

Regards,
Tom


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-06-05 Thread Tom Marcoen

Hey Eugen,

For some reason I did not receive your email. But I found your reply in the
archives.

Anyway, the goal is to have two computers, each with a Netgraph bridge node
and jails connecting to these bridges. I want to connect both bridges over
the Internet securely. Using a UDP tunnel and encrypting that with IPsec or
wireguard or  would be an option, but it would be nicer if I could use
a Netgraph-native option.

Regards,
Tom

On Wed, 27 May 2020 at 10:06, Tom Marcoen  wrote:

> Hey all,
>
> I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
> to me!) so bare with me, please.
>
> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
> and I was looking at some of the examples provided in
> /usr/share/examples/netgraph and now have the following question.
> The udp.tunnel example shows an iface point-to-point connection but it is
> unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
> or tunnel it through SSH, but I was wondering whether there exists a nice
> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> traffic on the inside hook and sending out encrypted traffic on the outside
> hook.
>
> Regards,
> Tom
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: On Netgraph

2020-05-27 Thread Eugene Grosbein

27.05.2020 15:06, Tom Marcoen wrote:

> Hey all,
> 
> I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
> to me!) so bare with me, please.
> 
> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and
> I was looking at some of the examples provided in
> /usr/share/examples/netgraph and now have the following question.
> The udp.tunnel example shows an iface point-to-point connection but it is
> unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
> or tunnel it through SSH, but I was wondering whether there exists a nice
> Netgraph solution, e.g. a node with two hooks, receiving unencrypted
> traffic on the inside hook and sending out encrypted traffic on the outside
> hook.

There is ng_mppc(4) netgraph node capable to perform relatively weak MPPE 
encryption
(and/or compression) but it is designed to work with ng_ppp(4) node 
encapsulating IP packets into PPP frames.
I doubt it's very efficient for inter-jail traffic.

Why do you need encryption for inter-jails traffic in first place?
Encryption is needed for traffic passing untrusted channels where data 
interception is possible
but inter-jail traffic does not leave the kernel at all until it hits 
destination jail.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

On Netgraph

2020-05-27 Thread Tom Marcoen

Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and
I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.

Regards,
Tom
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 246706] [netgraph] kernel panic due to corrupted memory

2020-05-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246706

Bug ID: 246706
   Summary: [netgraph] kernel panic due to corrupted memory
   Product: Base System
   Version: 11.3-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: panic
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: n...@freebsd.org
  Reporter: eu...@freebsd.org
CC: a...@freebsd.org, a...@freebsd.org, gleb...@freebsd.org,
m...@freebsd.org, melif...@freebsd.org

I run multiple routers using FreeBSD 11.3-STABLE/amd64 355108 and net/mpd5
daemon that dynamically creates/destroys ngXXX interfaces for multiple PPPoE
clients. Routers have ECC memory.

Since 11.1-RELEASE, the kernel was running it rock stable over 2 years until
yesterday one of routers paniced inside NETGRAPH code producing usable
crashdump and I have kernel.debug.

The server sends its logs to remote syslog collector and latest line sent
before panic was "Accepting PPPoE connection" produced by PppoeListenEvent()
function of mpd5 code:
https://sourceforge.net/p/mpd/svn/2239/tree/trunk/src/pppoe.c#l1356

Then mpd5 continued executing the function PppoeListenEvent() but an attempt to
create ng_tee(4) node and connect it to ng_pppoe(4) by sending NGM_MKPEER
message resulted in kernel panic. Note that stock gdb 6.1.1 shows backtrace
incorrectly so I use gdb 9.1:

Reading symbols from /data/crash/PPPOE11/kernel.debug...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x40
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80624dc0
stack pointer   = 0x28:0xfe012499f6d0
frame pointer   = 0x28:0xfe012499f700
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2576 (mpd5)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at 0x802fda6b =
db_trace_self_wrapper+0x2b/frame 0xfe012499f380
vpanic() at 0x804f5e2e = vpanic+0x17e/frame 0xfe012499f3e0
panic() at 0x804f5ca3 = panic+0x43/frame 0xfe012499f440
trap_pfault() at 0x80778540 = trap_pfault/frame 0xfe012499f490
trap_pfault() at 0x80778589 = trap_pfault+0x49/frame 0xfe012499f4f0
trap() at 0x80777c1d = trap+0x29d/frame 0xfe012499f600
calltrap() at 0x80758983 = calltrap+0x8/frame 0xfe012499f600
--- trap 0xc, rip = 0x80624dc0, rsp = 0xfe012499f6d0, rbp =
0xfe012499f700 ---
ng_add_hook() at 0x80624dc0 = ng_add_hook+0x20/frame 0xfe012499f700
ng_mkpeer() at 0x80624a0c = ng_mkpeer+0x6c/frame 0xfe012499f750
ng_apply_item() at 0x80622d7f = ng_apply_item+0x3ef/frame
0xfe012499f7d0
ng_snd_item() at 0x8062278e = ng_snd_item+0x17e/frame
0xfe012499f800
ngc_send() at 0x806329b3 = ngc_send+0x1a3/frame 0xfe012499f8a0
sosend_generic() at 0x805868ea = sosend_generic+0x4fa/frame
0xfe012499f950
kern_sendit() at 0x8058d246 = kern_sendit+0x286/frame
0xfe012499fa10
sendit() at 0x8058d591 = sendit+0x191/frame 0xfe012499fa70
sys_sendto() at 0x8058d3ed = sys_sendto+0x4d/frame 0xfe012499fac0
amd64_syscall() at 0x80778f18 = amd64_syscall+0x378/frame
0xfe012499fbf0
fast_syscall_common() at 0x80759290 = fast_syscall_common+0x101/frame
0xfe012499fbf0
--- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80279378a, rsp =
0x7fffdfffda08, rbp = 0x7fffdfffda50 ---
Uptime: 64d17h37m40s
Dumping 457 out of 4073 MB:..4%..11%..22%..32%..43%..53%..64%..71%..81%..92%

__curthread () at ./machine/pcpu.h:234
234 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:234
#1  doadump (textdump=1) at /home/src/sys/kern/kern_shutdown.c:320
#2  0x804f5a1d in kern_reboot (howto=260) at
/home/src/sys/kern/kern_shutdown.c:388
#3  0x804f5e68 in vpanic (fmt=, ap=0xfe012499f420)
at /home/src/sys/kern/kern_shutdown.c:784
#4  0x804f5ca3 in panic (fmt=) at
/home/src/sys/kern/kern_shutdown.c:715
#5  0x80778540 in trap_fatal (frame=0xfe012499f610, eva=64)
at /home/src/sys/amd64/amd64/trap.c:899
#6  0x80778589 in trap_pfault (frame=0xfe012499f610, usermode=0)
at /home/src/sys/amd64/amd64/trap.c:744
#7  0x80777c1d in trap (frame=0xfe012499f610) at
/home/src/sys/amd64/amd64/trap.c:438
#8  
#9  0x80624dc0 in ng_findhook (node=0xf80092840600,
name=0xf800921e9978 "left2right") at
/home/src/sys/netgraph/ng_base.c:1128
#10 ng

Re: Netgraph VLANs on Hyper-V

2020-04-10 Thread Paul Thornton


Hi,

I have recently been testing with jails, vnet and netgraph on ESXi - so 
not Hyper-V - but to make this work I needed to:


ngctl msg vmx0: setpromisc 1
ngctl msg vmx0: setautosrc 0

outside of the jail when setting up netgraph (where vmx0 is the "real" 
NIC that the ng_vlans are part of).


and then I had to set the mac address for the ngeth interface that was 
set to be put into the jail


ifconfig ngeth0 ether 02:00:01:02:03:04

Once done, and the jail started, ngeth0 worked as expected.

In ESXi, the portgroup that vmx0 is connected to allowed spoofing and 
promiscuous mode.


Paul.


On 10/04/2020 08:07, Reshad Patuck wrote:

Hi,

I am trying to use ng_vlan on Hyper-V to deploy vnet jails.
The "Enable MAC address Spoofing" setting on the Hyper-V host is enabled.
However when I try to use ng_vlan I am not able to reach the jail.
If I change this to if_vlan instead everything works fine.

Is there something that creating a VLAN using ifconfig does that ng_vlan
does not.
The same setup works well on VMware ESXi, Xen and KVM.

I am not sure if this is relevant to my issue but the hn1 devices sysrc's
changes when I use different vlan methods:

no vlan:
dev.hn.1.rxfilter: 9
dev.hn.1.hwassist: 17

if_vlan:
dev.hn.1.rxfilter: 20
dev.hn.1.hwassist: 17

ng_vlan:
dev.hn.1.rxfilter: 9
dev.hn.1.hwassist: 0

All the other sysrc's either stay the same or seem to be counters.
I can provide you with scripts to setup vlans and jails with both if_vlan
and ng_vlan if that helps.

Any help understanding what these sysrc's do, or on how I could get ng_vlan
to work would be very appreciated.

Best,

Reshad
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


--
Paul Thornton

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1383 matches

Mail list logo