On 14/03/2011, Gert Doering wrote:
> > [...] Multiple openvpn daemons on different interfaces and
> > same port.
> That's one possible use case, but not how I understood Federico.
That's part of my use case, not all.
Please let me summarize what I've read in this discussion:
* some people are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/03/2011, David Sommerseth wrote:
> As Davide Brini already mentioned, I really wonder if this issue is
> due to lack of --multihome in your configuration, combined with
> listen on 0.0.0.0.
Thank you for restating Davide's answer, which I someho
On 13/03/2011, Peter Stuge wrote:
> Federico Heinz wrote:
> > Because I don't know it at configuration time.
> You said that you already have a solution in place for dealing with
> interface reconfiguration.
I said I have a solution in place to restart OpenVPN when the
config
On 12/03/2011, Peter Stuge wrote:
> Federico Heinz wrote:
> > What I'm trying to solve here is a much simpler (and, in my case,
> > frequent) use case: I'm starting several instances of OpenVPN,
> > and I need each of them to listen on specific interfaces, but
> &
On 12/03/2011, Joe Patterson wrote:
> I'm all for adding flexibility, but this really seems like a
> solution to a problem for which there's hardly ever *not* a better
> work-around.
As I just mentioned in an answer to Peter, listening on 0.0.0.0
doesn't work reliably on my setup, please refer to
On 12/03/2011, Peter Stuge wrote:
> There are components in your system which *will* know when your
> address is reconfigured. Please just configure them to reconfigure
> OpenVPN. This would seem to be a good use for the management
> interface in OpenVPN.
I'm not worried abut the IP number *changi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/2011, David Sommerseth wrote:
> Sorry that you haven't received any response quickly. Most of us
> here are having full time jobs which is not directly related to
> OpenVPN.
I'm sorry if I sounded like I felt that answers were slow in coming
I'm sorry, folks, I'd like to ask for some clarification.
My patch was NAK'd on implementation issues. I offered alternatives
to them. I got no answer to them.
Should I bother implementing one of the alternatives, or will the
patch be disregarded nonetheless? If the patch does stand a chance to
b
On 09/03/2011, Markus Kötter wrote:
> David Sommerseth wrote:
> > 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
On 09/03/2011, Gert Doering wrote:
> I can understand why this feature is desirable - there are a couple
> of problems with the implementation, though.
> - From a code modularity point of view, socket stuff should not go
>to options.c, but to socket.c
I understand that with "socket stuff"
-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
On 09/03/2011, Alon Bar-Lev wrote:
> I don't understand why it is needed.
> You can always start openvpn and override configuration via
> command-line.
> So add --local "$(/sbin/ip addr show dev wlan0 | grep inet | sed
> 's#.*inet \(.*\)/.*#\1#')" parameter while starting it.
Sure: there's a huge
Author: Federico Heinz
Accept "local if:" option.
The current 'local' configuration directive allows for two types of
values: IP addresses and DNS hostnames. This is not enough for users
of dynamic DNS services who must restart OpenVPN when their IP
address changes, because
13 matches
Mail list logo
