Am 22.10.12 00:40, schrieb Jonathan K. Bullard:
> A Tunnelblick user has reported odd behavior with name resolution
> failures. I can't tell if it is a bug in OpenVPN, a bug in the
> documentation, or something else. The behavior is apparently the same
> in OpenVPN 2.2.1 and 2.3alpha1.
>
> The 2.3 man page says:
>
> --resolv-retry n
> If hostname resolve fails for --remote, retry resolve for n
> seconds before failing.
> Set n to "infinite" to retry indefinitely.
> By default, --resolv-retry infinite is enabled. You can
> disable by setting n=0.
>
>
> But the behavior seems very different:
>
> If a name resolution failure (caused, for example, by losing the
> network connection) occurs
> and --resolv-retry is:
>
> 1, the first resolution failure terminates the connection;
> 5, resolution attempts are made dozens of times per second,
> seemingly forever; or
> 10, resolution attempts are made every five seconds, seemingly
> forever.
>
>
> Any ideas if this is a program bug, a documentation bug, or something
> else, for example, a problem that only occurs on OS X?
I guess a programming bug.
The number of retries for a resolv is defined as (fail_wait_interval is
fixed to 5):
int resolve_retries = (flags & GETADDR_TRY_ONCE) ? 1 :
(resolve_retry_seconds / fail_wait_interval);
so if resolv-retry < 5 resolve_retries is set to 0 giving you a direct
failure. Without trying you should then see a USR1 and openvpn will
directly do the next connection attempt without waiting the 5s delay.
On a quick glance I cannot see a way to tell openvpn to have a fixed
number of connection retries after it quits.
Arne
