Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Thanks for your report. Please post the _complete_ Tunnelblick log.
And if you can also post the Console log, that would be very helpful. You can
filter entries using the word Tunnelblick. See
http://code.google.com/p/tunnelblick/wiki/cConsoleLog
Original comment by jkbull...@gmail.com on 2 Nov 2012 at 1:26
GoogleCodeExporter
commented
8 years ago The most common cause of this situation is that there is a Tunnelblick dialog
window which is open and awaiting your response. It may be covered by other
windows, so you should minimize all other windows to make sure they are not
covering it.Original comment by jkbull...@gmail.com on 4 Nov 2012 at 1:06
GoogleCodeExporter
commented
8 years ago No there is no other dialog shown, I see only the notification dialog thah
shows the disconnected tunnel in red.
Here the console log relative to the openvpn log of above:
02/11/12 13:48:35,397 Tunnelblick[3074]: Configuration file
/Users/luca/Library/Application Support/Tunnelblick/Configurations/phoenix.conf
needs ownership/permissions repair
02/11/12 13:48:48,984 Tunnelblick[3074]: Securing configuration file
/Users/luca/Library/Application Support/Tunnelblick/Configurations/phoenix.conf
02/11/12 13:48:49,008 authexec[3126]: executing
/Applications/Tunnelblick.app/Contents/Resources/installer
02/11/12 13:48:49,112 Tunnelblick[3074]: Secured configuration file
/Users/luca/Library/Application Support/Tunnelblick/Configurations/phoenix.conf
02/11/12 13:48:49,604 Tunnelblick[3074]: Keychain item retrieved successfully
for service = 'Tunnelblick-Auth-phoenix' account = 'username'
02/11/12 13:48:49,615 Tunnelblick[3074]: Keychain item retrieved successfully
for service = 'Tunnelblick-Auth-phoenix' account = 'password'
02/11/12 13:49:03,066 Tunnelblick[3074]: Received fatal signal 10.
02/11/12 13:49:03,067 Tunnelblick[3074]: signal_handler: Starting cleanup.
02/11/12 13:49:03,067 Tunnelblick[3074]: DEBUG: Cleanup: Entering cleanup
02/11/12 13:49:03,067 Tunnelblick[3074]: DEBUG: Cleanup: Removing status bar
item
02/11/12 13:49:03,124 Tunnelblick[3074]: DEBUG: Cleanup: Unregistering
hotKeyEventHandler
02/11/12 13:49:03,124 Tunnelblick[3074]: DEBUG: Cleanup: Setting
callDelegateOnNetworkChange: NO
02/11/12 13:49:03,125 Tunnelblick[3074]: DEBUG: Cleanup: Will
killAllConnectionsIncludingDaemons: NO
02/11/12 13:49:03,125 Tunnelblick[3074]: DEBUG:
killAllConnectionsIncludingDaemons: has checked for active daemons
02/11/12 13:49:03,125 Tunnelblick[3074]: DEBUG:
killAllConnectionsIncludingDaemons: will use killAll
02/11/12 13:49:03,133 Tunnelblick[3074]: DEBUG:
killAllConnectionsIncludingDaemons: requested killAll
02/11/12 13:49:04,078 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
02/11/12 13:49:04,079 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 43864064
02/11/12 13:49:04,079 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
02/11/12 13:49:04,080 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 43864064
02/11/12 13:49:04,080 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
02/11/12 13:49:04,081 Tunnelblick[3074]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 43864064
02/11/12 13:49:20,469 com.apple.launchd.peruser.501[297]:
([0x0-0x2e62e6].net.tunnelblick.tunnelblick[3074]) Exited: Killed: 9
Original comment by lucadist...@gmail.com on 5 Nov 2012 at 5:44
GoogleCodeExporter
commented
8 years ago [deleted comment]Encountering same issue on Mountain Lion 10.8.2 and Tunnelblick 3.3beta28
(build 3153)
Console Log:
11/28/12 2:32:14.566 PM Tunnelblick[27543]: DEBUG: currentIPInfo(Name):
[63.232.111.128, 25823, 205.233.73.66]
11/28/12 2:32:15.006 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:15.006 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:15.007 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:15.007 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:15.007 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:15.007 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:15.278 PM Tunnelblick[27543]: openvpnstart stderr from
unloadKexts:
DEBUG: Became root
DEBUG: runAsRoot: Executing /sbin/kextunload -q -b net.tunnelblick.tun
DEBUG: Stopped being root
DEBUG: stdout:
DEBUG: stderr:
DEBUG: runAsRoot: Finished execution
11/28/12 2:32:26.318 PM Tunnelblick[27543]: DEBUG: currentIPInfo(Name): IP
address info was fetched in 386 milliseconds
11/28/12 2:32:26.318 PM Tunnelblick[27543]: DEBUG: currentIPInfo(Name):
[63.232.111.128, 25823, 205.233.73.66]
11/28/12 2:32:26.750 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:26.751 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:26.751 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:26.751 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:26.751 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: Entered
11/28/12 2:32:26.752 PM Tunnelblick[27543]: DEBUG:
cancelAllIPCheckThreadsForConnection: No active threads for connection 51496448
11/28/12 2:32:26.994 PM Tunnelblick[27543]: openvpnstart stderr from
unloadKexts:
DEBUG: Became root
DEBUG: runAsRoot: Executing /sbin/kextunload -q -b net.tunnelblick.tun
DEBUG: Stopped being root
DEBUG: stdout:
DEBUG: stderr:
DEBUG: runAsRoot: Finished execution
Original comment by NickForm...@gmail.com on 28 Nov 2012 at 9:35
GoogleCodeExporter
commented
8 years ago Further private emails with NickFormerlyKnownAsPrince resolved his situation,
which did not hang and has nothing to do with this Issue.Original comment by jkbull...@gmail.com on 4 Dec 2012 at 9:45
GoogleCodeExporter
commented
8 years ago Same here: upgraded from 3.3beta18 to 3.3beta21a and Tunnelblick stopped
working. Tunnelblick seems to connect, even gets an IP address, but then the
GUI (the menubar icon) disappears and a "Tunnelblick" process keeps the CPU
busy. At this point the tun0 interface is gone and the VPN is not working. As
there's no GUI part to terminate any more, the only solution is to kill the
process.
Attached are 3 files:
* tunnelblick-sample-1.txt, a "sample" of the spinning "Tunnelblick", taken via
"Activity Monitor"
* tunnelblick-consolelog.txt, what syslog captured during all this
* tunnelblick-vpnlog.txt, the log output from the "log" statement in the
openvpn configuration file, verbose=4.Original comment by ckujau on 4 Dec 2012 at 9:53
Attachments:
GoogleCodeExporter
commented
8 years ago FWIW, downgrading to 3.3beta18. Upgrading to 3.3beta22 shows the same symptoms
as beta21. And beta24 requires a .tblk configuration, which I don't have. Also,
starting openvpn manually (using the version beta24 ships with) seems to work:
$ sudo chown -R root:wheel
/Applications/Non-Apple/Tunnelblick.app/Contents/Resources/tun.kext
$ sudo kextload
/Applications/Non-Apple/Tunnelblick.app/Contents/Resources/tun.kext
$ kextstat | grep net.tunnelblick.tun
146 0 0xffffff7f807cf000 0x6000 0x6000 net.tunnelblick.tun (1.0) <7 5 4 1>
$ cd ~/Library/Application Support/Tunnelblick/Configurations
$ sudo
/Applications/Non-Apple/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3-a
lpha1/openvpn --config vpn.confOriginal comment by ckujau on 4 Dec 2012 at 10:24
GoogleCodeExporter
commented
8 years ago Ahah! Thank you, ckujau, for providing all those details and trying the
different versions. I now see at least part of what is going on.
I think this is caused by a bug in the DNS flush logic. That is fixed in
Tunnelblick 3.3beta28.
(There may be a bug in the error handling logic, too, which is causing the
hang, and I will look into that, but the error shouldn't have happened in the
first place.)
You can easily make a Tunnelblick VPN Configuration and try 3.3beta28. See
http://code.google.com/p/tunnelblick/wiki/cConfigT#Creating_and_Installing_a_Tun
nelblick_VPN_Configuration
Or you can try not flushing DNS for the configuration (using 3.3beta21):
1. Open the VPN Details… window
2. Click on a configuration in the left pane to select it
3. Click on the Settings tab, then on the Advanced button
4. Un-check "Flush DNS cache after connecting or disconnecting"
Original comment by jkbull...@gmail.com on 4 Dec 2012 at 10:41
GoogleCodeExporter
commented
8 years ago Bingo! Unchecking "Flush DNS cache..." did the trick. I've only tested with
beta21 now, will test beta28 later on. Thanks!Original comment by ckujau on 4 Dec 2012 at 11:40
GoogleCodeExporter
commented
8 years ago To clarify: When you try 3.3beta28, you should be able to put back the
checkmark in "Flush DNS cache..."
I'm leaving this Issue open until I fix the bug in the error handling logic or
determine that there isn't one.Original comment by jkbull...@gmail.com on 5 Dec 2012 at 12:14
GoogleCodeExporter
commented
8 years ago Yep, 3.3beta28 works with "Flush DNS cache...". On a side note, I'm not too
happy about all this .tblk stuff and beta28 forced itself into /Applications
now, but oh well, it works and it's free so I'll stop whining now :-)
Thanks for fixing this!Original comment by ckujau on 5 Dec 2012 at 3:15
GoogleCodeExporter
commented
8 years ago Tunnelblick is in /Applications so that it is in a securable place. This is
necessary to avoid the security issues raised in Issue 212.Original comment by jkbull...@gmail.com on 16 Dec 2012 at 2:15
GoogleCodeExporter
commented
8 years ago /Applications is just as secure as any other root-controlled location. Issue
212 is about (getting rid of) SUID code, and rightly so. Unfortunately Apple is
making use of SUID/SGID binaries too and AFAICS they provide zero documentation
about alternatives akin to Linux' capabilities(7) or other approaches.Original comment by ckujau on 17 Dec 2012 at 1:25
Original issue reported on code.google.com by
lucadist...@gmail.comon 2 Nov 2012 at 1:04