Rewrite manpage section about --multihome
PATCH 1/1 Rewrite manpage section about --multihome
Part of the information was confusing, part was outdated, and part was just not making sense.
Pointed out in trac#348.
Also add note about Linux IPv4-mapped issues as per trac#306.
--- doc/openvpn.8 | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-)
doc/openvpn.8 +17 -12
@@ -2343,18 +2343,23 @@ is NOT specified. .\"********************************************************* .TP .B \-\-multihome -Configure a multi-homed UDP server. This option can be used when -OpenVPN has been configured to listen on all interfaces, and will -attempt to bind client sessions to the interface on which packets -are being received, so that outgoing packets will be sent out -of the same interface. Note that this option is only relevant for -UDP servers and currently is only implemented on Linux. - -Note: clients connecting to a -.B \-\-multihome -server should always use the -.B \-\-nobind -option. +Configure a multi-homed UDP server. This option needs to be used when +a server has more than one IP address (e.g. multiple interfaces, or +secondary IP addresses), and is not using +.B \-\-local +to force binding to one specific address only. This option will +add some extra lookups to the packet path to ensure that the UDP reply +packets are always sent from the source address that the client's packet +was sent to. This is not supported on all platforms, and it adds more +processing, so it's not enabled by default. + +Note: this option is only relevant for UDP servers, for TCP this happens +automatically. + +Note 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with +multiple IPv4 address, connections to IPv4 addresses will not work +right on kernels before 3.14, due to missing kernel support for the +IPv4-mapped case. .\"********************************************************* .TP .B \-\-echo [parms...]
Signature · 1 line
1.8.3.2
PATCH v2 1/1 Rewrite manpage section about --multihome
Part of the information was confusing, part was outdated, and part was just not making sense. Pointed out in trac#348.
Also add note about Linux IPv4-mapped issues as per trac#306.
--- doc/openvpn.8 | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-)
doc/openvpn.8 +16 -12
@@ -2343,18 +2343,22 @@ is NOT specified. .\"********************************************************* .TP .B \-\-multihome -Configure a multi-homed UDP server. This option can be used when -OpenVPN has been configured to listen on all interfaces, and will -attempt to bind client sessions to the interface on which packets -are being received, so that outgoing packets will be sent out -of the same interface. Note that this option is only relevant for -UDP servers and currently is only implemented on Linux. - -Note: clients connecting to a -.B \-\-multihome -server should always use the -.B \-\-nobind -option. +Configure a multi-homed UDP server. This option needs to be used when +a server has more than one IP address (e.g. multiple interfaces, or +secondary IP addresses), and is not using +.B \-\-local +to force binding to one specific address only. This option will +add some extra lookups to the packet path to ensure that the UDP reply +packets are always sent from the address that the client is +talking to. This is not supported on all platforms, and it adds more +processing, so it's not enabled by default. + +Note: this option is only relevant for UDP servers. + +Note 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with +multiple IPv4 address, connections to IPv4 addresses will not work +right on kernels before 3.14, due to missing kernel support for the +IPv4-mapped case. .\"********************************************************* .TP .B \-\-echo [parms...]
Signature · 1 line
1.8.3.2
Quoted 6 lines · Gert Doering
Part of the information was confusing, part was outdated, and part was just not making sense. Pointed out in trac#348.
Also add note about Linux IPv4-mapped issues as per trac#306.
ACK as per discussion on #openvpn-devel.
Arne
Your patch has been applied to the master and release/2.3 branch.
commit abe18c69a61b42e5ac68b77f66198fc15be99e31 (master) commit d40de75fea9c9fa17b68e13be67731b6ccec9fb5 (release/2.3)
Author: Gert Doering Date: Fri Apr 25 21:19:15 2014 +0200
Rewrite manpage section about --multihome
Signed-off-by: Gert Doering <[email protected]...>
Acked-by: Arne Schwabe <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8635--
kind regards,
Gert Doering
* Gert Doering
doc/openvpn.8 is NOT specified. · line 2362
Quoted 4 lines
doc/openvpn.8 +4
-0+Note 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with +multiple IPv4 address, connections to IPv4 addresses will not work +right on kernels before 3.14, due to missing kernel support for the +IPv4-mapped case.
This isn't entirely accurate. There are two patches that are required for this to work:
«ipv6: make IPV6_RECVPKTINFO work for ipv4 datagrams»
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b261c75a99f29c93a0b6babfc180cdf566bd654
«ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg»
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c8e6ad0829a723a74cd2fea9996a3392d2579a18
Only the first one is in Linux 3.14, the second one is not (it first appeared in 3.15-rc1). You should probably say «before 3.15» instead.
Another thing worth noting though, is that Ubuntu backported both patches to the 3.13-based kernel they are shipping as part of Ubuntu 14.04 «Trusty». So it works out of the box there, which is great news because it's a "Long Term Support" release that will probably be popular on servers in the years to come. The patches will eventually make it into the previous LTS release 12.04 «Precise» too, as part of the upcoming 12.04.5 point release (expected in August).
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284535
Tore
* Tore Anderson
Quoted 3 lines
The patches will eventually make it into the previous LTS release 12.04 «Precise» too, as part of the upcoming 12.04.5 point release (expected in August).
Just a little followup here to clarify in case you decide to add this info to the documentation. The 12.04.5 «Precise» fixes will come about by importing a collection of packages from 14.04. They call this a Hardware Enablement Stack (the purpose is to bring support for modern hardware and its drivers to the older but still-supported releases):
https://wiki.ubuntu.com/Kernel/LTSEnablementStack
Anyway, what I wanted to clarify is that if a user is installing 12.04.5 from scratch, then it should default to using the kernel package from 14.04, and the IPv6 multihoming fixes should be there out of the box. However if the user is on <=12.04.4, doing a distribution upgrade is not sufficient, he would also need to manually install the kernel from the 14.04 Hardware Enablement Stack to get the required fixes. This is done by installing the package "linux-generic-lts-trusty".
Here's some suggested text:
The fixes are also present in Ubuntu 12.04.5 «Precise» (kernel package "linux-generic-lts-trusty" required) and in Ubuntu 14.04 «Trusty».
Tore
Hi,
Quoted 7 lines · Tore Anderson
* Tore Anderson
Quoted 3 lines
The patches will eventually make it into the previous LTS release 12.04 «Precise» too, as part of the upcoming 12.04.5 point release (expected in August).
Just a little followup here to clarify in case you decide to add this info to the documentation.
I'm not sure if I really want to go there. It is a lot of details, for one specific Linux variant, while the manage is also read by people on other Linux variants, or even (gasp!) non-Linux users.
You're right, of course, about the 3.15 bit. So maybe change this to:
-----------------------------------------------------------
Note 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with multiple IPv4 address, connections to IPv4 addresses will not work right on kernels before 3.15, due to missing kernel support for the IPv4-mapped case (some distributions have ported this to earlier kernel versions, though).
-----------------------------------------------------------
I'm happy to put your detailed text into the trac ticket, though, so someone finding "it does not work!" and looking into trac can find them.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...* Gert Doering
Quoted 1 line
I'm not sure if I really want to go there.
Completely fine by me, just getting the information out there, so you can decide what to do with it, :-)
Quoted 2 lines
I'm happy to put your detailed text into the trac ticket, though, so someone finding "it does not work!" and looking into trac can find them.
Yeah, about that...I'm not sure your trac is completely healthy. Even though I submitted issue #306, I get "Warning: No permissions to add a comment." when trying to add info, there's no way I can close the ticket (which I think it should be, as it's not an OpenVPN bug in the first place), and I never got any e-mail notification about your comments on that ticket either.
Tore
Hi,
Quoted 3 lines · Tore Anderson
Quoted 1 line
I'm not sure if I really want to go there.
Completely fine by me, just getting the information out there, so you can decide what to do with it, :-)
Yeah, thanks for the details and the links. It helps.
Quoted 9 lines
Quoted 2 lines
I'm happy to put your detailed text into the trac ticket, though, so someone finding "it does not work!" and looking into trac can find them.
Yeah, about that...I'm not sure your trac is completely healthy. Even though I submitted issue #306, I get "Warning: No permissions to add a comment." when trying to add info, there's no way I can close the ticket (which I think it should be, as it's not an OpenVPN bug in the first place), and I never got any e-mail notification about your comments on that ticket either.
Our trac doesn't like this ticket, I think - took me 4 attempts to actually get the comment in, but *closing* worked at the first go...
(I think you can't close it, as that needs more permissions than "default", but the comment-no-permission thing is some sort of weird thing we need to look into, "we" being "Samuli and Eric", I think...)
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...* Gert Doering
Quoted 7 lines
Quoted 6 lines
Yeah, about that...I'm not sure your trac is completely healthy. Even though I submitted issue #306, I get "Warning: No permissions to add a comment." when trying to add info, there's no way I can close the ticket (which I think it should be, as it's not an OpenVPN bug in the first place), and I never got any e-mail notification about your comments on that ticket either.
Quoted 7 lines
Our trac doesn't like this ticket, I think - took me 4 attempts to actually get the comment in, but *closing* worked at the first go...
(I think you can't close it, as that needs more permissions than "default", but the comment-no-permission thing is some sort of weird thing we need to look into, "we" being "Samuli and Eric", I think...)
Ack. FWIW I did get e-mail notification/cc for your updates #6 and #7 on ticket #306 today. I didn't get that for any of the previous updates. So either something got fixed in the last four months (when update #5 was posted), or that problem occurs intermittently too.
Your new manpage patch looks good to me, btw.
Tore
Quoted 12 lines
Quoted 3 lines
I'm happy to put your detailed text into the trac ticket, though, so someone finding "it does not work!" and looking into trac can find them.
Yeah, about that...I'm not sure your trac is completely healthy. Even though I submitted issue #306, I get "Warning: No permissions to add a comment." when trying to add info, there's no way I can close the ticket (which I think it should be, as it's not an OpenVPN bug in the first place), and I never got any e-mail notification about your comments on that ticket either.
Tore
Hi,
If Trac gives you "No permissions" it either means that you're either not logged in or that Trac believes you're not logged in. If you clear cookies from your browser and login again it should be fine.
Looking at Trac permissions it seems there's no way to grant a "<x> may close his own tickets" type privileges. Currently only admins (core devs) can close tickets.
Email addresses are synced from LDAP to Trac once per day, which would explain the email problem if you logged in to Trac the first time before filing the ticket in question.
Signature · 5 lines
Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
PATCH 1/1 More IPv6-related updates to the openvpn man page.
In reply to Tore AndersonPoint to correct kernel version for --multihome and IPv4-mapped addresses (3.15, Tore Anderson).
Remove old reference to http://www.greenie.net/ from the IPv6 section, as the code and documentation in here is more current than on that site. Some more additions and clarifications.
--- doc/openvpn.8 | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
doc/openvpn.8 +10 -6
@@ -2357,8 +2357,9 @@ Note: this option is only relevant for UDP servers. Note 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with multiple IPv4 address, connections to IPv4 addresses will not work -right on kernels before 3.14, due to missing kernel support for the -IPv4-mapped case. +right on kernels before 3.15, due to missing kernel support for the +IPv4-mapped case (some distributions have ported this to earlier kernel +versions, though). .\"********************************************************* .TP .B \-\-echo [parms...]
@@ -5471,9 +5472,11 @@ option can be used BEFORE this option to produce debugging information. .SS IPv6 Related Options .\"********************************************************* The following options exist to support IPv6 tunneling in peer-to-peer -and client-server mode. As of now, this is just very basic -documentation of the IPv6-related options. More documentation can be -found on http://www.greenie.net/ipv6/openvpn.html. +and client-server mode. All options are modeled after their IPv4 +counterparts, so more detailed explanations given there apply here +as well (except for +.B \-\-topology +, which has no effect on IPv6). .TP .B --ifconfig-ipv6 ipv6addr/bits ipv6remote configure IPv6 address
@@ -5504,7 +5507,8 @@ pool starts at .B ipv6addr and increments by +1 for every new client (linear mode). The .B /bits -setting controls the size of the pool. +setting controls the size of the pool. Due to implementation details, +the pool size must be between /64 and /112. .TP .B --ifconfig-ipv6-push ipv6addr/bits ipv6remote for ccd/ per-client static IPv6 interface configuration, see
Signature · 1 line
1.8.3.2
[Openvpn-devel] [PATCH applied] Re: More IPv6-related updates to the openvpn man page.
Patch has been applied to the master and release/2.3 branches.
commit 2a97e69e71d4afb9c32268890e13db19cb73196b (master) commit 268e211b2cf77f88f7ebb69a241337c82b3cc086 (release/2.3)
Author: Gert Doering Date: Sat Apr 26 13:30:54 2014 +0200
More IPv6-related updates to the openvpn man page.
Signed-off-by: Gert Doering <[email protected]...>
Acked-by: Tore Anderson <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8642--
kind regards,
Gert Doering