> ACK! That makes sense to me. But it needs to be clearly visible in some
> kind of requirements list. If we don't have that, that's probably
> something we should have.
You could even start your shell scripts with something like:
test "x$(pwd)" = "x`pwd`" || (echo "This shell is not good enou
> There shouldn't be a difference, I did quite a bit of Googling just to
> be sure. For example, the Dash shell seems to be used often as
> POSIX-compliance reference implementation. From
POSIX mandates $() so any posix shell will support it. The issue is
with non-POSIX shells, if you do want to
> You can test this by making sure the TTL is set low enough on your server
> records (say 60 seconds), make sure that your client will do a new DNS
> lookup with the proper TTL (you can check this with 'dig'). Then connect
> to your server and break the connection after one minute and then
> reco
>> * Move the man page to a better format than the pure man page format.
>> Are there some good tools/formats like ascii2man or DocBookXML which
>> could help easing the maintenance of our documentation?
> Docbook XML for sure is a lot more verbose than asciidoc or roff.
> I would tend to avoid Do
>> > Having apps that can't be tricked into downloading random DLLs from
>> > strange websites would certainly be a good thing ;-)
>> Upgrade to a sane system, like GNU/Linux and all your apps will be fixed
>> in one fell swoop,
> "if they were built with a sane rpath".
AFAIK, that's usually the c
> Having apps that can't be tricked into downloading random DLLs from
> strange websites would certainly be a good thing ;-)
Upgrade to a sane system, like GNU/Linux and all your apps will be fixed
in one fell swoop,
Stefan
>> Let's not add more complexity to openvpn itself, I'd be much happier if
> You just don't understand.
> The complexity *WILL* be in OpenVPN, if we decide to support
> "route-gateway dhcp" for non-Windows platforms.
I'm not sure what "route-gateway dhcp" does, so maybe that's part of the
reason
>>> Implementing a DHCP client within OpenVPN tends to make this a more
>>> self-contained problem.
>> I don't think OpenVPN should get into the DHCP business.
>> Especially because this is not a problem specific to OpenVPN: the same
>> problem of refreshing DHCP info happens with ethernet and with
> Implementing a DHCP client within OpenVPN tends to make this a more
> self-contained problem.
I don't think OpenVPN should get into the DHCP business.
Especially because this is not a problem specific to OpenVPN: the same
problem of refreshing DHCP info happens with ethernet and with wifi when
y
> My understanding of dhcp is that the client is supposed to
> automatically reconfigure on lease expiration
Yes.
> or whenever the link goes up and down.
Not necessarily, and that's the problem.
> I suppose it's possible that there are dhcp clients
> that exit when the link goes down and must
> bring the interfaces up
> start dhcp client (if not triggered directly from the interfaces)
> start openvpn
That is a misconfiguration in my book. The only correct configuration
is when the dhcp client is triggered from the interface. After all,
openvpn may take half an hour to get the connect
>> I think if the user just starts the dhcp client on an interface
>> independently from the moment the interface goes up (or down), this
>> is simply a misconfiguration.
> I'm not sure I understand. Are you saying that manually starting
> a dhcp client means that the system is mis-configured bec
> In either case we'd be looking at an openvpn configuration
> directive (or 2) that takes a command to run once
> the link comes up (and down). If that was in place then
> any of A, B, C, or D, or your choice of using an ifup/ifdown
> script would all work.
BTW, there are generic tools to run/st
> That's a very good suggestion! I just tried this with OpenVPN-ALS
> (adito), and while the average performance is slightly lower (java
> vs. compiled code?), the throughput inconsistency is not there, rather
> it's only the case with OpenVPN!
IIUC OpenVPN-ALS is not comparable in that it works i
> because i really believe in open source software I've decided to check
> all sorts of configurations to check problems with tcp tunneling.
This makes it sound like OpenVPN's performance is lower than some
comparable non-Free software.
Have you actually compared OpenVPN's performance to some othe
>> If someone could give at least some vaguely plausible scenario,
>> that'd help.
> Maybe there's more than one tunnel and there's some stupid
> load balancing going on using a hosts file? (Along with
> deleting all non-vpn routes.)
[ Setting aside the fact that using OpenVPN's broken handling o
> I was doing some considerations back and forth here before starting this
> second round. The issue is that it changes the behaviour quite a lot
> from what might be expected from earlier versions (if you're used to the
> former behaviour).
I'm at a loss when it comes to try and imagine someone
> - From the following review discussion, a few other things needs to be
> changed and I hope you are willing to look into adopting your patch to
> those guidelines. This is also to follow the standards [1] we try to
> introduce as well.
Sure, I'd like to get this in the main OpenVPN code, so I'l
>> I'm fine with whichever path you choose. But just bear in mind, some
>> systems might not have IPv6 support - which breaks portability ...
> On the unixish side, there is no system which has tun/tap today but
> does not have IPv6.
What about embedded systems using uclibc compiled "without ipv6
> You are right in regards to dynamic memory allocation. You're using
> static array allocation, defined by MAX_IPS_PER_HOSTNAME. This value is
> set to 100. Where did you take this number from? IMHO, that sounds to
> be fairly high.
Actually, I don't use static allocation but stack allocation
> When reviewing the patch "FQDN for routes should expand to all IPs"
> today, I spotted that there is a function called getaddr() (renamed to
> getaddr_all() in the mentioned patch). This function again makes use of
> the old gethostbyname() function. This is not compatible with IPv6
> addresses
> Thanks a lot for you patch! In general, it very looks good. Can you
> elaborate a little bit on how you have tested this patch?
I've been using it on my client machines for the last few months.
This is not a very extensive test, obviously: they're all configured
identically and so they all loo
[ I've sent this in the past already, but just trying to make sure it
doesn't get lost somewhere. ]
When specifiying an FQDN for the network part of a route, OpenVPN should
setup a route for each IP associated with that FQDN. Currently, it just
chooses one of the IPs at random instead, which le
> One the one hand people expect OpenVPN to be rock-solid in both
> stability and security. In order to maintain this standard of quality,
> there needs to be a rigorous process of patch vetting. On the other
> hand, as an open source project, OpenVPN needs to be transparent and
> open to con
> 2009.11.20 -- Version 2.1_rc22
Thanks.
For those like me who need to use routing commands with hostnames mapped
to more than a single IP, here's an updated patch. IIUC the previous
patch should still apply, tho with some offsets.
Stefan
Index: route.c
===
> This is the right place to submit bug reports.
Thanks.
> Having said that, your bug report seems more like a feature request since
> routing commands/APIs generally do not support DNS A-record expansion
> as a standard feature.
I understand that it's halfway between feature request and bugrepo
Ping?
Stefan
>>>>> "Stefan" == Stefan Monnier writes:
> I've posted a bug report at:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2872760&group_id=48978&atid=454719
> since since I haven't heard any reaction
I've posted a bug report at:
http://sourceforge.net/tracker/index.php?func=detail&aid=2872760&group_id=48978&atid=454719
since since I haven't heard any reaction for almost 2 weeks now
(although the report includes a patch which works well, at least for
me), I'm wondering whether it was the right
28 matches
Mail list logo
