[PATCH] Growl Support/Location Support/Other improvements

[GoogleCodeExporter]

This patch adds several improvements to tunnelblick:
- Growl Support
- Basic Location Support
- Better menu icon behaviour
- Support for Icon Sets
- Configuration window

The zip file contains all additional files added. The Growl framework will
need to be added to the project, and it needs to compile with the 10.5 sdk
if you use the settings window.

Original issue reported on code.google.com by redninj...@gmail.com on 15 May 2009 at 12:14

Attachments:

• allchanges.diff
• changes.zip

[GoogleCodeExporter]

I just integrated and compiled this with the latest svn.
These are great additions I would definately like to see in Tunnelblick.
Growl integration works nicely for me.
Configuration window looks good too, however it looks to me it does atm only 
support
reading and not writing values to the config files.

If you want to integrate and compile this yourself you have to add besides the 
Growl
framework the    SystenConfiguration.framework !

And to get the MenuBar Icon working properly add a build phase which copies the
IconSets/TunnelBlick.TBMenuIcons Folder in 
Ressources/IconSets/TunnelBlick.TBMenuIcons

However I would understand if the devs didn't want to accept the drop of 10.4 
support
for the preferences window, so perhaps we should try to make this backwards 
compatible ?

Cheers Marco

Original comment by masc...@gmail.com on 18 Jun 2009 at 7:04

[GoogleCodeExporter]

I would like to put these into the source-tree, but is there any way the 
changes can
be separated from each other? It makes it much easier for (future) debugging. I
assume that the config window and location support are too interrelated, but the
Growl support and icon behavior seem separable.

And can you point me to what the Leopard dependency is, so I can try to change 
it to
work on Tiger, too?

Thanks.

Original comment by jkbull...@gmail.com on 19 Jun 2009 at 6:30

[GoogleCodeExporter]

I've tried to split up the changes. Hopefully these diffs will apply, i havent 
had
time to test them.

animation fixes should only need those diffs to work correctly, and adding the 
build
phase to copy the icons into Resources/IconSets/

growl support will need the TBGrowlDelegate class added to the project, along 
with
the Growl framework

location support needs the SystemConfiguration framework added

configuration window needs all the window classes added. the leopard 
requirement is
that the windows use NSWindowController, which is only available in Leopard 
afaik.

Original comment by redninj...@gmail.com on 20 Jun 2009 at 4:33

Attachments:

• locationsupport.diff
• growlsupport.diff
• animfixes.diff
• settingswindow.diff

[GoogleCodeExporter]

AFAIK NSWindowController is available for 10.4 but the used NSViewController is 
the
problem. We could either eliminate this dependency, but I think that would 
require
some rewrite of redninja83's code.
After some research I think we could quiet easily use Matt Gemmels 
<a href="http://mattgemmell.com/source">SS_PrefsController</a> (which is 10.4
compatible) for the management of the costum views in the preferences window 
without
much rewrite.

Original comment by masc...@gmail.com on 20 Jun 2009 at 8:40

[GoogleCodeExporter]

Thank you very much. I won't be able to work on this for the next day or two, 
but am
looking forward to getting it working in the tree and, eventually, in a release!

Original comment by jkbull...@gmail.com on 20 Jun 2009 at 12:23

[GoogleCodeExporter]

Sorry it took so long to get to this. I have put the animation changes and icon 
sets implementation into the trunk 
as r120.  I added a few minor changes, including a change to the creation of 
the set from the files (made it more 
robust if file names are weird; see comments in the file).

Original comment by jkbull...@gmail.com on 1 Aug 2009 at 4:36

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Not implementing the other proposed features.

Original comment by jkbull...@gmail.com on 9 Sep 2010 at 12:27

• Changed state: WontFix

[GoogleCodeExporter]

for everyone longing for growl support in tunnelblick, I recommend using up and 
down scripts in combination with growlnotify to get proper connect / disconnect 
notifications.
As long as there is no direct support in tunnelblick, this can be a feasible 
solution.
You can check out the details here : http://marcoschuh.de/wp/?p=680

Original comment by masc...@gmail.com on 4 Dec 2010 at 11:32

[GoogleCodeExporter]

I don't know anything about growl. Can someone please explain why you want to 
use growl in Tunnelblick and what you would use it for? Is it to get a pop-up 
window whenever a tunnel is connected/disconnected or are there other things it 
can do?

Is the main use to be notified when a connection dies so you know you should 
stop browsing "sensitive" websites (since your work is not going through the 
VPN anymore)? If so, I'm considering a way to have Tunnelblick optionally block 
all (or some) network access when a tunnel dies, so no data "leaks" outside the 
VPN.

Original comment by jkbull...@gmail.com on 5 Dec 2010 at 2:01

[GoogleCodeExporter]

Exactly growl is a cocoa frameworks that provides support for user 
notifications, and I like being notified of Tunnel Connection / Disconnection / 
Reconnection.
And although the icon kind of informs you , it's not as eye catching, and by 
using growl you are also informed which tunnel broke down / reconnected (I 
sometimes use several simultaneously).
Btw. Growl is very popular and wide-spread and is used bye several dozen 
(cocoa) applications (http://growl.info/applications.php) like e.g. firefox and 
adium.
Also it is not a requirement to have growl installed, if it is the user gets 
notified, if not nothing breaks (i think it uses some NSNotification stuff). 
And it is very costumizeable, you can choose in the included PrefPane, if and 
how notifications are displayed on an per app basis.

I'm not so into the sensitive browsing issue, because I usually use the local 
connection for browsing and the tunnel for securely accessing remote 
ressources, but I think it's a great idea to have the option to block traffic 
if a specific connection drops, so no data leaks out of the VPN.

Regards Marco

Original comment by masc...@gmail.com on 5 Dec 2010 at 2:22

[GoogleCodeExporter]

Masch82: You might want to consider using the "pre-connect" and 
"post-disconnect" script facility in Tunnelblick 3.2 (just released stable 
version).

* They don't interfere with the OpenVPN up/down scripts and thus allow the use 
of "Set nameserver"

* The down/up cycle isn't invoked when the connection has a temporary problem 
and recovers. Using the OpenVPN up/down scripts, if a temporary problem 
happens, the down script is invoked, which will allow Time Machine backups. If 
a backup starts before the up script is executed, the backup will continue 
after the tunnel is re-established (or maybe it will just fail because of 
connection problems while the tunnel is brought back up, which could be even 
worse.)

* See http://code.google.com/p/tunnelblick/wiki/wUsingScripts, which describes 
the scripts.

Original comment by jkbull...@gmail.com on 5 Dec 2010 at 9:24

[GoogleCodeExporter]

Thanks jk, that sounds promising, but after looking into the code am I correct 
that :
* these scripts lie only in the App Bundles Ressource folder
* these are global scripts that apply to all connections, and not on a per 
connection basis ?

if so, what would be the probability of inclusion of patch that :
* allows "pre-connect.sh" (and post) to be placed in "~/Library/Application 
Support/Tunnelblick/Configurations" on a per connection basis, e.g. by naming 
them %connectionname%-pre-connect.sh.
* correctly ensurs security of the scripts permissions.

either 10% or rather 90%.
Meaning, would it make sense for me to spend a few hours figuring this out ...

Regards Marco.

Original comment by masc...@gmail.com on 6 Dec 2010 at 8:20

[GoogleCodeExporter]

No, these scripts are on a per-connection basis. They are not in the 
application's  Contents/Resources. They appear in xxx.tblk/Contents/Resources, 
i.e., in a "Tunnelblick VPN Configuration". And they are secured (as are all 
contents of a .tblk).

You were probably confused by the variable name in the code in openvpnstart.m. 
"tblkPath" is not a pointer to the Tunnelblick application's path; it is a 
pointer to the path to the connection's .tblk package. (Or it's null if there 
isn't a .tblk -- i.e., we are connecting a with bare .ovpn or .conf file). 
Because a .tblk is an OS X package, it has most of it's goodies in 
Contents/Resources.

Take a look at the link in comment #11, and 
http://code.google.com/p/tunnelblick/wiki/wPkgs, which describes the format of 
a .tblk package. (If you have any suggestions for improving these docs, please 
let me know.)

Of course, if you want to know about every up/down of the connection, the 
pre-connect.sh and post-disconnect.sh won't do that -- in fact, that's their 
purpose.

By the way, using a .tblk also makes it unnecessary to hard-code the path to 
your up/down scripts -- you can place them in the .tblk/Contents/Resources 
also. In fact, including the scripts there means you don't need to refer to 
them in the configuration file, either.

Original comment by jkbull...@gmail.com on 6 Dec 2010 at 11:04

[GoogleCodeExporter]

Indeed I was confused with the tblkPath Pointer ...

This is great information. As it doesn't mess with openvpn stuff. The only 
small downside is that I can not detect successful connection opening easily, 
but by using the .tblk Bundle I get more security as all scripts get secured by 
tunnelblick automatically and now I also drop rights to user-level when 
executing external programs.

I updated my instructions accordingly.

Thanks for this great information jk.

I'm thinking of posting this to tunnelblick-discuss also, because the 
TimeMachine stuff could be of use to some ppl I think ... 

Regards Marco

Original comment by masc...@gmail.com on 8 Dec 2010 at 1:59

[GoogleCodeExporter]

The idea of a script that runs when a connection succeeds is interesting. I am 
inclined to add it.

My original idea was that the post-disconnect/pre-connect scripts would NOT be 
run if OpenVPN loses the connection and then regains it, but maybe that should 
be rethought. I'm not certain of what the code does. Right now I'm working on 
something else, but I hope to look into this soon. My point is that if you want 
those notifications, you may not get them.

You should post this to the Discussion Group, but maybe you should wait until I 
clarify the current behavior and whether or not that is what is desired. That's 
up to you. But if you do post now, please put in a disclaimer that the behavior 
may change in the near future.

Separately, I've been thinking about the TM icon not showing the on/off status. 
If there is a way to get SystemUIServer (or whatever it's called) to remove the 
icon, then put it back, maybe when put back it would show the correct status. I 
noticed that if you use System Preferences (in 10.6.5) to turn off TM, the icon 
doesn't reflect that (as you said). But if you uncheck, then recheck, the "Show 
TM status in the menu bar", when it reappears it shows dim, indicating that TM 
is off. Could you eavesdrop on the Apple Events that occur when you 
uncheck/recheck that box? Maybe System Preferences sends an event to 
SystemUIServer, and we could do that.

Original comment by jkbull...@gmail.com on 8 Dec 2010 at 2:56

[GoogleCodeExporter]

I've been tracking this issue and wanted Growl support just for the
connection tracking. I'm using OpenVPN to pass down an ipv6 tunnel to my
laptop and on unstable wifi (like university campuses), its hard to tell
when its my VPN flapping or actual ipv6 issues.

I

NOT

the

to

System

Original comment by roger.bu...@gmail.com on 8 Dec 2010 at 5:59

[GoogleCodeExporter]

@jkbull That would be awesome, perhaps something like the possibility to use 
additional post-connect / pre-disconnect scripts ...

I see - I will wait a bit with posting to the Discussion group.

> If there is a way to get SystemUIServer (or whatever it's called) to remove 
the icon, then put it back, maybe when put back it would show the correct 
status.
that's exactly the case, and that's how I implemented it now in my 
TMMenuIconReloader utility thats used by my scripts.

> Could you eavesdrop on the Apple Events that occur when you uncheck/recheck 
that box? Maybe System Preferences sends an event to SystemUIServer, and we 
could do that.
Yes I had that idea too - but I wasn't able to figure out how the PrefPane 
instructs the MenuIcon to reload. When I have some time, I'll look into it 
again.
I would rather prefer to use some Notification or API call than to load/reload 
the MenuIcon like i do now - for it would be less invasive. I'll have to see.

@roger 
> "I NOT the to System"
??? whatever that means" you could still use the method of up / down scripts in 
your openvpn config file to achieve notification of VPN "flapping" in 
combination with some growlnotify usage as I see it.
You can look at my scripts to get an idea (although I just changed from up/down 
to pre/post scripts like discussed previously with jkbull).

Original comment by masc...@gmail.com on 8 Dec 2010 at 9:13

[GoogleCodeExporter]

@jkbull I figured out the correct way to send the TMMenuIcon a prefs changed 
notification. Should have seen it in the first place though ...

So no need for the reload MenuExtra hack now anymore.

I will update the packages on my site accordingly, but will wait till the 
clarification of the addition of other pre/post scripts is out, until posting 
the instructions the list.

Regards Marco 

Original comment by masc...@gmail.com on 14 Dec 2010 at 3:23

[GoogleCodeExporter]

Great! I'm curious as to how the notification gets made. I'm not sure I 
understand what you mean by "the addition of other pre/post scripts" -- do you 
mean the "connected.sh" script?

I have committed the source code changes so a "connected.sh" script in a .tblk 
will be run (as root) when/if a successful connection is made to the VPN, and a 
"reconnecting.sh" script will be run (as root) whenever OpenVPN has detected 
that the VPN has been disconnected or lost and OpenVPN is trying to reconnect. 
(If the reconnection attempt is successful, the resulting connection would 
cause connected.sh to be called.)

The next beta release (in the next couple of weeks) will include these changes. 
(The documentation will be updated at that time, too.)

So the sequence would be as follows:

1. USER ASKS for connection (or one is started by 'connect on launch')

2. pre-connect.sh will run before attempting to make a connection

3. connect.sh will run if/when the connection is successfully made

3a. reconnect.sh will run each time (if any) that OpenVPN loses the connection 
and is trying to reconnect

3b. connect.sh will run each time (if any) a reconnection attempt is successful

4. USER ASKS for connection to be terminated (or quit Tunnelblicks and it isn't 
a 'when computer starts' configuration)

5.post-disconnect.sh will run after disconnecting

The idea is that a reconnect attempt should NOT trigger the 
pre-connect.sh/post-disconnect.sh sequence because a reconnect is really a 
different thing. It lets the script writer treat it the same, of course, but 
for many purposes I think a reconnect should be ignored -- for example, for 
tun/tap loading and turning Time Machine on and off.

I think that the OpenVPN up/down scripts are executed during reconnection 
attempts. I'm not sure of the exact sequence -- I think it is that the OpenVPN 
down script is executed when the connection is lost, then the reconnection 
attempt is made, then (if successful) the OpenVPN up script is executed.

There is one caveat with these scripts -- the connect.sh, reconnect.sh, and 
post-disconnect.sh scripts in a "when computer starts" configuration will only 
be executed if Tunnelblick is running at the time the connection, reconnection, 
or disconnection occurs. (The pre-connect.sh script runs, though, no matter 
what.)

Original comment by jkbull...@gmail.com on 15 Dec 2010 at 1:45

[GoogleCodeExporter]

This is great, thanks for implementing this feature.

> Great! I'm curious as to how the notification gets made.
It's just a one liner via NSDistributedNotificationCenter :
[[NSDistributedNotificationCenter defaultCenter] 
postNotificationName:@"com.apple.backup.prefschanged" 
object:@"com.apple.backupd"];
Even though I noticed this before, I didn't get it to work, because not only 
the notification name has to be set, also the sender object needs to be refered 
to as "com.apple.backupd" - otherwise TimeMachine Menu Icon doesn't pick up the 
notification.

I just compiled recent svn and tested the new script stuff - it works great for 
me, with one minor glitch :
When a connected.sh script is used inside my .tlbk the Tunnelblick icon 
animates, but then displays off state, even though the connection is up and my 
script gets executed. When I rename the connected.sh script, the icon works 
fine (although of course my script is not executed).
I wonder if you could reproduce this ...

> It lets the script writer treat it the same, of course, but for many purposes 
I think a reconnect should be ignored -- for example, for tun/tap loading and 
turning Time Machine on and off.
This is exactly the way I'm using it, only for notification purposes.

> I think that the OpenVPN up/down scripts are executed during reconnection 
attempts. I'm not sure of the exact sequence
I think so too, altough I have not verified it as I don't need those scripts 
anymore ...

> in a "when computer starts" configuration will only be executed if 
Tunnelblick is running at the time the connection, reconnection, or 
disconnection occurs. (The pre-connect.sh script runs, though, no matter what.)
Could you elaborate "when computer starts configuration" ? Does that mean when 
starting openvpn as a service (? LaunchDaemon ? LaunchAgent ?) and tunnelblick 
is not running while that happens, the scripts won't trigger ? I think that's 
obvious ?

Original comment by masc...@gmail.com on 15 Dec 2010 at 11:23

[GoogleCodeExporter]

Thanks for trying the new scripts feature out. I'll look into the problem you 
report and post here about it.

"When computer starts" is a Tunnelblick option that causes a launchd execution 
of Tunnelblick's "openvpnstart" binary when the computer starts (Tunnelblick 
itself does not start). openvpnstart itself runs the pre-connect.sh script, 
loads tun/tap kexts as needed, launches OpenVPN and then goes away. Only 
OpenVPN is left running, so there is nothing that will know to execute 
connect.sh, reconnect.sh, or post-disconnect.sh.

If/when a user logs in and launches Tunnelblick, Tunnelblick looks for running 
OpenVPN processes, and tries to attach itself to each one's management port and 
log file and the separate log file of any up/down/leasewatch scripts associated 
with it. This is done by using some conventions about the filenames of the log 
files. If it successfully attaches to the management port, then Tunnelblick is 
monitoring the situation, and can execute connect.sh, reconnect.sh, or 
post-disconnect.sh.

This behavior would be a bit difficult to change; it would involve keeping a 
program running alongside OpenVPN that would connect up to the management port, 
accept the connect, reconnect, and disconnect notifications, and execute 
connect.sh, reconnect.sh, or post-disconnect.sh. The problem comes in when 
Tunnelblick starts up and wants to connect to the management port so the user 
can control OpenVPN.

Original comment by jkbull...@gmail.com on 15 Dec 2010 at 11:39

[GoogleCodeExporter]

I have committed a fix (r1235 -- Build 2235) to the problem with the 
Tunnelblick icon showing 'closed' after connecting with a .tblk with a 
connected.sh script. It turns out it was a timing problem; executing the script 
changed the timing just enough to cause the failure. This fix will be in the 
next beta release.

Original comment by jkbull...@gmail.com on 16 Dec 2010 at 4:51

[GoogleCodeExporter]

Excellent, the patch fixes the problem for me too.

I have updated my instructions to match the new tunnelblick script 
capatibilites :
http://marcoschuh.de/wp/?p=680
And as well updated the TimeMachineMenuIconReloader to use proper Notifications.

I will post it to the discussion list soon.

> "When computer starts" is a Tunnelblick option that causes a launchd 
execution of Tunnelblick's "openvpnstart" binary when the computer starts
Ah I see, this makes sense, but I don't think it poses a big problem. If the 
user chooses this option he's responsible for e.g. adding costum scripts 
launched (after tunnelblick) during system boot to perfom wanted actions. He 
could write a costum launch daemon script or something, that conditionally 
performs stuff (like disabling TimeMachine).

Maybe a NSAlertPanel or something should notify the user that scripts other 
than pre-connect.sh won't be executed in "when computer starts" mode when he 
chooses it.

Original comment by masc...@gmail.com on 16 Dec 2010 at 9:04

[GoogleCodeExporter]

Good idea about the alert panel -- I've put it into the trunk.

Original comment by jkbull...@gmail.com on 17 Dec 2010 at 2:45

[GoogleCodeExporter]

1) I had to remove the alert panel described in my comment 24 above.

2) Tunnelblick 3.2beta02 has been released and includes the scripts described 
in my comment 19 above.

Original comment by jkbull...@gmail.com on 2 Feb 2011 at 11:06