[Bug 288882] ipv6 flowlabel handling seems inconsistent and the documentation is too well-hidden

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=22 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

Re: Technical documentation for Synopsys Ethernet QoS Controller (eqos)

On Sun, 3 Aug 2025 10:43:20 +1000 Peter Jeremy wrote: > I'm trying to extend eqos(4) to support more of the controller's > functionality: Checksum offload and ideally TCP offload. I have > "Rockchip RK3568 TRM Part2 V1.1-20210301.pdf" but that's missing > d

Technical documentation for Synopsys Ethernet QoS Controller (eqos)

I'm trying to extend eqos(4) to support more of the controller's functionality: Checksum offload and ideally TCP offload. I have "Rockchip RK3568 TRM Part2 V1.1-20210301.pdf" but that's missing documentation on the DMA interface and there are some discrepancies between it

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Mark Linimon changed: What|Removed |Added Status|In Progress |Open -- You are receiving this mai

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|b...@freebsd.org Keywords

[Bug 273851] missing documentation for udp_set_kernel_tunneling

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273851 Graham Perrin changed: What|Removed |Added Severity|Affects Only Me |Affects Some People Assi

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 --- Comment #9 from Graham Perrin (non-committing) --- Re: comment #7 > aim for the #bugs channel. Correcting myself: the #freebsd-bugs channel. Apologies for the noise. -- You are receiving this mail because: You are on

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 --- Comment #8 from Graham Perrin (non-committing) --- > … add the URL of the review to the See also: field. … For clarity, I mean: * your D37096 * not my D37086 -- You are receiving this mail because: You are on the CC list for th

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Graham Perrin (non-committing) changed: What|Removed |Added CC||grahamper...@gmail

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Benedict Reuschling changed: What|Removed |Added CC||b...@freebsd.org

[Bug 206165] resolv.conf(5) is missing documentation on options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Marek Zarychta changed: What|Removed |Added CC||n...@freebsd.org,

[Bug 194872] [netmap] documentation for bridge/pkt-gen doesn't mention the updated interface format (netmap:X, vale:X) nor how to configure a specific ring

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194872 Vincenzo Maffione changed: What|Removed |Added Resolution|--- |FIXED Status|New

[Bug 194872] [netmap] documentation for bridge/pkt-gen doesn't mention the updated interface format (netmap:X, vale:X) nor how to configure a specific ring

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194872 Adrian Chadd changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are

documentation

Hi. Can any one describe packetflow in kernel structures and the algorithm how netisr is worked. and how packet are queued and scheduled to CPU I want to try to optimize its algorithm of working Thank you. ___ freebsd-net@freebsd.org mailing list http

Re: RADIX_MPATH Documentation Feedback Request

: >> I am hoping to get the documentation, along with more enhancements completed >> within a month. >> >> The main reason for this delay is because I am suspending RADIX_MPATH related >> work at the moment, and focusing on fixing IPv6 code instead. >> >> The Fr

Re: RADIX_MPATH Documentation Feedback Request

In article <111911.24641.10834@localhost> you wrote: > I am hoping to get the documentation, along with more enhancements completed > within a month. > > The main reason for this delay is because I am suspending RADIX_MPATH related > work at the moment, and focusing on fix

Re: RADIX_MPATH Documentation Feedback Request

Makes perfect sense. Thank you for the followup and if there is anyway that I could assist on direct tasks then feel free to give me a hollar and Ill do what I can to assist. On Mon, Oct 10, 2011 at 11:21:39PM -0700, Qing Li wrote: > I am hoping to get the documentation, along with m

Re: RADIX_MPATH Documentation Feedback Request

I am hoping to get the documentation, along with more enhancements completed within a month. The main reason for this delay is because I am suspending RADIX_MPATH related work at the moment, and focusing on fixing IPv6 code instead. The FreeBSD IPv6 implementation in -CURRENT, stable/8 and

Re: docs/120945: [patch] ip6(4) man page lacks documentation for TCLASS option.

Synopsis: [patch] ip6(4) man page lacks documentation for TCLASS option. State-Changed-From-To: patched->closed State-Changed-By: gjb State-Changed-When: Sat Jun 11 01:58:52 UTC 2011 State-Changed-Why: MFCd to stable/7. http://www.freebsd.org/cgi/query-pr.cgi?pr=120

OT: Libnet 1.1 documentation

Hi folk, some one know where can i found the oficial documentation of Libnet 1.1.x ? or may be an tuto of it ? Thanks a lot. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" &

Re: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option.

Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Changed-When: Mon 1 Sep 2008 13:37:24 UTC Responsible-Changed-Why: Someone else best grab this until I learn how to MFC in Subversion. h

Re: ng_netflow documentation

On Mar 29, 2006, at 11:19 AM, Bart Van Kerckhove wrote: Dear list, I have been looking into ng_netflow lately for traffic analyzing. It seems that this would do everything i'd ever need - though I have a hard time tracking down (working) examples, or FAQ's/howto's/documenta

ng_netflow documentation

Dear list, I have been looking into ng_netflow lately for traffic analyzing. It seems that this would do everything i'd ever need - though I have a hard time tracking down (working) examples, or FAQ's/howto's/documentation. I've done the most obvious things, googled it, sea

Re: IPSEC documentation

but I have some things to add in this handbook's documentation: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html Fist from all, very thanks by this documentation, because is very good. 1-) "Note: In FreeBSD 5.X, the functionality provided by the gifconfig(8) utilit

Re: IPSEC documentation

On Fri, Jan 20, 2006 at 09:53:33PM +, Brian Candler wrote: > > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > > If we would also have NAT-T support, FreeBSD would be the best choice > > > of VPN concentrator. > > I just saw this patch posted on the ipsec-tools-devel list: >

Re: IPSEC documentation

> On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. I just saw this patch posted on the ipsec-tools-devel list: http://ipsec-tools.sf.net/freebsd6-natt.diff It's for FreeBSD 6 but also

Re: [fbsd] Re: IPSEC documentation

Jeremie Le Hen (jeremie) writes: > > I personally find the gif(4)/transport mode setup neater than the > single tunnel mode - though I am not aware of initial constrains > when IPSec RFCs were written - especially because one can look after the > traffic going through the VPN link in a very natura

Re: [fbsd] Re: [fbsd] Re: IPSEC documentation

Hi Phil, > > I personally find the gif(4)/transport mode setup neater than the > > single tunnel mode - though I am not aware of initial constrains > > when IPSec RFCs were written - especially because one can look after the > > traffic going through the VPN link in a very natural way. I forgot t

Re: [fbsd] Re: IPSEC documentation

Hi, Brian, Eric, > I still think that gif + IPSEC tunnel mode (as currently documented) is not > a good approach, especially if it's the *only* mode of operation to be > documented and hence implicitly recommended as the 'right' way to do it. AFAIK, using both gif(4) and IPSec tunnel mode is actu

Re: IPSEC documentation

Brian Candler wrote: > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > T

Re: IPSEC documentation

On Fri, Dec 30, 2005 at 12:17:08PM +, Brian Candler wrote: [simultaneous negociations] > You could have a crypto accelerator card even in a low-end CPU. Yep, but it doesn't help so much, for the same reasons. Crypto accelerator for IPSec traffic is really more important ! > My concern is wit

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 01:38:15PM +0100, VANHULLEBUS Yvan wrote: > > "Known issues: > > - Non-threaded implementation. Simultaneous key negotiation performance > > should be improved." > > > > I think that would limit its usefulness as a scalable concentrator, if the > > comment is still valid

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 01:35:21PM +0100, VANHULLEBUS Yvan wrote: > > As it happens this FreeBSD box is also acting as a NAT gateway using pf > > (myhost is on a private IP) and actually its external IP is also private - > > it sits behind a second NAT firewall. So maybe that's where the problem >

Re: IPSEC documentation

Hi, This now goes a little bit off topic from original subject of IPsec documentation, but we have made an implementation of the BEET (A Bound End to End Tunneling) mode IPsec on FreeBSD 5 and 6 (http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-04.txt). The implementation is

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 12:25:49PM +, Brian Candler wrote: > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. > > /usr/ports/security/ipsec-tools/pkg-descr says: > > "Known issues:

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 12:14:00PM +, Brian Candler wrote: > On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: [] > > ports/net/sl2tps > > I was rather surprised that I just got IPSEC tunnel mode working between > Windows XP and FreeBSD; and then afterwards I also got transport

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. /usr/ports/security/ipsec-tools/pkg-descr says: "Known issues: - Non-threaded implementation. Simultaneous key negotiation performance s

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > Did someone tried such a setup ? > > I plan to do so. > > Just have to find ios images that support l2tp and ipsec for my 1601R > or 2611 and bigger flash modules (I've been given them two weeks ago, > hardware upgrade is the easy p

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > Hi. > > VANHULLEBUS Yvan wrote: > >>- L2TP + IPSEC transport mode (= Windows road warrier) > >Did someone tried such a setup ? > >is there a L2TPD daemon running on FreeBSD which could be used for > >that ? > I'm successfully using se

Re: IPSEC documentation

"Clark Gaylord" <[EMAIL PROTECTED]> writes: > Yeah, what is the story with that anyway? Is anyone working on it? Is > there hope? Iirc, Yvan made a patch (don't remember the target branch, sorry), but it seems that NAT-T might be patent encumbered (*). Anyway, Net & Open included NAT-T in their

Re: IPSEC documentation

just need a vpn3000 or other equipment that can act like vpn3000 as remote side. Emmanuel Dreyfus wrote a nice paper about building a vpn concentrator that could act as a server for the cisco vpn client : http://www.netbsd.org/Documentation/network/ipsec/rasvpn.html Iirc, the same could be done o

Re: IPSEC documentation

On Thu, 29 Dec 2005 09:50:47 +0300, "Alexey Popov" <[EMAIL PROTECTED]> said: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. Yeah, what is the story with that anyway? Is anyone working on it? Is there hope? --ckg -- Clark Gaylord Blacksburg, VA US

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: Hi, > OK, I'll buy gif + IPSEC transport mode as an option. Seems there's a rfc about this kind of setup : http://rfc.net/rfc3884.html -- Juste un truc, ca te ferait mal au cerveau de lire les messages auxquels tu reponds ? -+-RMD in :

Re: IPSEC documentation

Hi. VANHULLEBUS Yvan wrote: - L2TP + IPSEC transport mode (= Windows road warrier) Did someone tried such a setup ? is there a L2TPD daemon running on FreeBSD which could be used for that ? I'm successfully using security/racoon and net/sl2tps with Windows XP/2003 L2TP clients. I've tried pre-

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 05:43:39PM +0100, VANHULLEBUS Yvan wrote: > > Also excellent would be "bump in the wire" bridging, where the gateway > > negotiates transport-mode security on behalf of clients without their being > > aware of it, but as far as I know only OpenBSD supports that. > > What is

Re: IPSEC documentation

f userland IPSEC solutions which I don't think run under FreeBSD (FreeS/WAN, OpenS/WAN). All a bit of a nightmare really. Documentation would be good :-) > > I still think that gif + IPSEC tunnel mode (as currently documented) is not > > a good approach, especially if it's the

Re: IPSEC documentation

Brian Candler wrote: On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: gif/gre tunnels and ipsec transport mode are quite convenient when associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what yo

Re: IPSEC documentation

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes: Hi Yvan, > Did someone tried such a setup ? I plan to do so. Just have to find ios images that support l2tp and ipsec for my 1601R or 2611 and bigger flash modules (I've been given them two weeks ago, hardware upgrade is the easy part, for software,

Re: IPSEC documentation

Hi all. Coming a bit late in the discussion, but I guess I can provide some infos On Wed, Dec 28, 2005 at 03:31:06PM +, Brian Candler wrote: [] > I would like to rewrite this document (or see it rewritten) to include: > > - Gateways with IPSEC tunnel mode and static keys Well, this

Re: IPSEC documentation

On Wed, 28 Dec 2005 10:08:54 -0500, "Matt Emmerton" <[EMAIL PROTECTED]> said: > (which is already encrypted via HTTPS, but you can't be too safe!) Yes and no. There are substantial support and performance costs every time you encrypt. You can figure that encryption will cost you about 1/3 of you

Re: IPSEC documentation

On Wed, 28 Dec 2005 16:04:04 +0100, "Phil Regnauld" <[EMAIL PROTECTED]> said: > Yes, here using tunnel is indeed odd, it would make more sense > of using IPIP or just GRE in transport mode. I have often used GRE+IPsecTransport -- this allows routing protocols, link state (if you have G

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > case, perhaps what you want is an external IPSEC tunnel mode implementation > which attaches to a 'tun' device. That's yet another category which I hadn't > even considered] Any u

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote: > > This is a really strange approach which is almost guaranteed not to > > interoperate with other IPSEC gateways. > > It's probably for FreeBSD <-> FreeBSD setups, where it might make sense > to have an interface endpoint

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: > gif/gre tunnels and ipsec transport mode are quite convenient when > associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what you want is an external IPSEC tu

Re: IPSEC documentation

ree? If so I'll try to find the time to modify > > it. > > This perhaps would be a good _addition_ to the existing documentation -- > it's likely a configuration that many would want to set up, especially to > inter-operate with corporate networks (using commercial IPSec sol

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: Hi, > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again

Re: IPSEC documentation

> The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > > This is a really stra

Re: IPSEC documentation

Brian Candler (B.Candler) writes: > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode

IPSEC documentation

The IPSEC documentation at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) encapsulation and THEN encapsulate that again using IPSEC tunnel mode. e.g. notice where it shows spdadd W.X.Y.Z/32

mobileIP documentation

Can anybody point me to documentation about setting up home/foreign agents for IPv4/IPv6 mobility on FreeBSD 5? Thanks, Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to

Re: netgraph documentation?

On Tue, 4 Jun 2002 10:13:17 -0700 (PDT), Archie Cobbs <[EMAIL PROTECTED]> wrote: [.] > I don't think you can have a point-to-point interface who's > remote IP address is also local to your box. In other words, > this may not work on the same machine but it might work if > you use two different

Re: netgraph documentation?

Lars Eggert writes: > > I don't think you can have a point-to-point interface who's > > remote IP address is also local to your box. In other words, > > this may not work on the same machine but it might work if > > you use two different machines... can you try that? > > The addresses of the poin

Re: netgraph documentation?

Archie Cobbs wrote: > I don't think you can have a point-to-point interface who's > remote IP address is also local to your box. In other words, > this may not work on the same machine but it might work if > you use two different machines... can you try that? The addresses of the point-to-point i

Re: netgraph documentation?

Lars Eggert writes: > So I ignore the error for now, and make the TCP tunnel as follows: > > Server: > /usr/sbin/ngctl mkpeer iface dummy inet > /sbin/ifconfig ng0 10.10.10.1 10.10.10.2 > /usr/sbin/ngctl mkpeer ng0: ksocket inet inet/stream/tcp > /usr/sbin/ngctl msg ng0:in

Re: netgraph documentation?

Archie Cobbs wrote: >>/usr/sbin/ngctl mkpeer iface dummy inet >>/usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp >>/usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505 >>/usr/sbin/ngctl msg ng3:inet listen 1 >>ngctl: send msg: Operation not supported by device >> >> 2. Why can't I li

Re: netgraph documentation?

r iface dummy inet > /usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp > /usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505 > /usr/sbin/ngctl msg ng3:inet listen 1 > ngctl: send msg: Operation not supported by device > > So I guess I have two questions: > >

netgraph documentation?

Hi, I'm starting to play with netgraph, and there doesn't seem to be much documentation out there (other then the DaemonNews article, and the man pages.) For starters, I was going to modify the UDP tunneling example in the DaemonNews article to do TCP tunneling. However, I'm

Re: ARP API documentation?

--- Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > On Tue, Jan 22, 2002 at 09:22:12AM -0800, Kenneth Stailey wrote: > > Hi, > > > > I search and search but cannot find any documentation on the user-space > level > > API for ARP. I know of only two code exampl

Re: ARP API documentation?

On Tue, Jan 22, 2002 at 09:22:12AM -0800, Kenneth Stailey wrote: > Hi, > > I search and search but cannot find any documentation on the user-space level > API for ARP. I know of only two code examples in the tree (usr.sbin/arp/arp.c > and usr.sbin/ppp/arp.c) and I do not wish t

ARP API documentation?

Hi, I search and search but cannot find any documentation on the user-space level API for ARP. I know of only two code examples in the tree (usr.sbin/arp/arp.c and usr.sbin/ppp/arp.c) and I do not wish to play guessing games about the protocol. It's clear that you open a PF_ROUTE raw s