Heavy resource usage when trying to connect to unresolved host

[GoogleCodeExporter]

With 3.3beta21b (build 3114.3185), I noticed that my 2009-era MBP got very hot 
for no reason that I could understand. Peaking in top, I noticed that both 
Tunnelblick and openvpn were using lots of CPU time. At the moment, no network 
connections were active, so that Tunnelblick wouldn't be able to do much in any 
case. However, in the log I saw this:

2013-01-18 08:56:23 SIGUSR1[soft,init_instance] received, process restarting
2013-01-18 08:56:23 WARNING: No server certificate verification method has been 
enabled.  See http://openvpn.net/howto.html#mitm for more info.
2013-01-18 08:56:23 NOTE: the current --script-security setting may allow this 
configuration to call user-defined scripts
2013-01-18 08:56:23 WARNING: file 'djc-mbp.key' is group or others accessible
2013-01-18 08:56:23 RESOLVE: Cannot resolve host address: backup.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.
2013-01-18 08:56:23 RESOLVE: Cannot resolve host address: backup.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.
2013-01-18 08:56:23 SIGUSR1[soft,init_instance] received, process restarting
2013-01-18 08:56:23 WARNING: No server certificate verification method has been 
enabled.  See http://openvpn.net/howto.html#mitm for more info.
2013-01-18 08:56:23 NOTE: the current --script-security setting may allow this 
configuration to call user-defined scripts
2013-01-18 08:56:23 WARNING: file 'djc-mbp.key' is group or others accessible
2013-01-18 08:56:23 RESOLVE: Cannot resolve host address: vpn.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.
2013-01-18 08:56:23 RESOLVE: Cannot resolve host address: vpn.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.
2013-01-18 08:56:23 SIGUSR1[soft,init_instance] received, process restarting
2013-01-18 08:56:24 *Tunnelblick: Disconnecting; 'disconnect' button pressed
2013-01-18 08:56:24 WARNING: No server certificate verification method has been 
enabled.  See http://openvpn.net/howto.html#mitm for more info.
2013-01-18 08:56:24 NOTE: the current --script-security setting may allow this 
configuration to call user-defined scripts
2013-01-18 08:56:24 WARNING: file 'djc-mbp.key' is group or others accessible
2013-01-18 08:56:24 RESOLVE: Cannot resolve host address: backup.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.
2013-01-18 08:56:24 RESOLVE: Cannot resolve host address: backup.example.com: 
[HOST_NOT_FOUND] The specified host is unknown.

So (a) Tunnelblick could probably just check if any network connections are up 
before trying to connect, and (b) it probably shouldn't spin an infinite loop 
when DNS resolution for the VPN server fails.

Original issue reported on code.google.com by djc.ochtman on 18 Jan 2013 at 8:05

[GoogleCodeExporter]

There are two different things going on here:

1. Tunnelblick allows you to try to connect even if there is no network 
connectivity

2. OpenVPN allows you to retry resolves infinitely with no time between retries.

#1 is just the way it is. OS X doesn't have a way to test in for connectivity 
in general; it can only test for connectivity to a particular IP address or DNS 
name. So testing some generic website (google.com, for example) would tell 
whether Google is reachable, but not indicate that your VPN server is 
reachable, which is what is wanted. And since your VPN server (presumably) 
doesn't respond to web requests, we can't test that, either. So Tunnelblick 
lets OpenVPN try to do the connection without first trying to determine if 
OpenVPN will be able to.

#2 is controlled by OpenVPN options. For example, "resolv-retry 5" will try to 
resolve for five seconds before giving up. 

Original comment by jkbull...@gmail.com on 18 Jan 2013 at 10:56

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 19 Jan 2013 at 3:51

• Changed state: WontFix

[GoogleCodeExporter]

That's all well and good, but (a) I've not made any changes to my OpenVPN 
configuration file, (b) I don't even have resolv-retry set in it, and (c) it 
just started doing this after the latest update.

Original comment by djc.ochtman on 19 Jan 2013 at 4:09

[GoogleCodeExporter]

This has to do with being unable to resolve the hostname.

OpenVPN's "resolv-retry" defaults to retry forever.

Original comment by jkbull...@gmail.com on 19 Jan 2013 at 5:06