-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/03/2011, David Sommerseth wrote:
> Even though that shell trick isn't so obvious, I would say it
> solves exactly the same thing. It's not as pretty, but your patch
> does not give any extra advantages either.
It provides the only advantage it was meant to provide: a simpler
setup syntax that is easy to read and write.
> One is that you do resolve the IP address based on the device
> name. What if the IP address changes on that device? It would be
> anticipated by most users that it would then listen to the new IP
> address. When being done via the command line, it is much more
> obvious OpenVPN needs to be restarted on an IP address change.
AFAIK, te need to restart under such a circumstance is there for any
and all internet daemons that allow the user to bind to an interface,
so there's nothing unexpected here.
> Then there are is this issue with IPv6. It's not available in the
> coming 2.2 or earlier releases (unless you've added support patches
> for it). But we're soon (4-12 weeks) starting on the 2.3 beta
> cycle which will include full IPv6 support. And with IPv6 an
> interface can also multiple IP addresses, even without using
> aliasing in Linux. In fact, I wonder if it is even possible to
> assign multiple IPv4 addresses using iproute2 to a device without
> aliases. It might be something similar in *BSD as well. Your
> patch does not cover this scenario at all.
It's not meant to, since OpenVPN does not currently support listening
on a multi-membered subset of the system's IP addresses. In the
current scenario, then if you have an interface with more than one
address, we will be forced to choose one of them arbitrarily...
which is exactly what my patch does: it takes whatever IP address ends
up in the socket's IP address field.
Summing up: in the most likely case, my code does the expected
thing. In unlikely cases, it does as good as it can for the curren
OpenVPN implementation. If and when OpenVPN supports listening on
a list of IP addresses, the code can easily be upgraded to support
it, but it's impossible to do it before.
> [...] So socket.c needs a major overhaul and this feature must be
> implemented. When we manage this, we can bind to devices instead
> of IP addresses, as then OpenVPN would behave as expected by most
> users.
I understand that socket.c needs a major overhaul, but my patches
show two strategies how this useful behaviour can be implemented
*today* without much hassle. I think it would be better to include the
functionality now, at the same time providing a template of what
needs to be done for the future, than to delay the inclusion of useful
functionality to an unspecified time when socket.c finally gets its
overhaul.
Fede
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFNd3AJbPULDL0CxuARAnk+AKDryLC6e2QeJAZTSXWqGqgejkfvzQCfUcy+
7aajuzkOtZ0h2hgu3m/xtY8=
=qX6x
-----END PGP SIGNATURE-----
