Reset of autoConnect open in com.openvpn.tunneblick.plist

[GoogleCodeExporter]

What steps will reproduce the problem?

 1. Open Tunnelblick
 2. Select Details... from Tunnelblick icon
 3. Select Automatically connect on launch
 4. Close Details...
 5. Quit Tunnelblick
 6. Reopen Tunnelblick, you get connected (yay)
 7. Quit Tunnelblick
 8. Reopen Tunnelblick, you don't get reconnected (buh).

What is the expected output? What do you see instead?

  I would expect the plist option to automatically reconnect
  to survive across multiple restarts.

What version of Tunnelblick are you using? On what version of OS X? PPC or
Intel?

  Tunnelblick 3.0b10
  Mac OS X 10.5.6
  Intel

Please provide any additional information below.

  Examining the com.openvpn.tunnelblick.plist shows that
  the autoConnect field is getting unchecked every time that
  Tunnelblick is quit (when Details... has not been used).

  The plist is not changed until Tunnelblick is quit (i.e.,
  between steps 6 and 7 above, the autoConnect option is
  checked. After step 7, the autoConnect option is unchecked).

  These are the openvpn configurations in effect (replacing
  <remote-ip>, <remote-port>, <my-crt>, and <my-key> with
  real values):

  client
  dev tap
  proto udp
  remote <remote-ip> <remote-port>
  resolv-retry infinite
  nobind
  user nobody
  group nobody
  persist-key
  persist-tun
  mute-replay-warnings
  ca keys/ca.crt
  cert keys/<my-crt>
  key keys/<my-key>
  ns-cert-type server
  cipher BF-CBC
  comp-lzo
  verb 3

  I tried disabling persist-{key,tun} and {user,group} to see
  if that made a difference, and it did not appear to.

Original issue reported on code.google.com by jim.robi...@gmail.com on 7 Apr 2009 at 4:33

[GoogleCodeExporter]

I am having the same Problem. Is there any solution to it?

Original comment by david.se...@googlemail.com on 22 Apr 2009 at 4:22

[GoogleCodeExporter]

This issue (and a dup of it, #83) and two "discussions" ("Set Nameserver" 
setting
doesn't stick" and "Two issues") complain about the "Automatically connect on 
launch"
and "Set Nameserver" checkboxes being cleared spontaneously. I think I 
understand
what is causing the problem and how to fix it. 

Given steps to reliably reproduce the problem with "Automatically connect on 
launch",
I looked at the code that sets and clears that preference. The preference is
set/cleared (via NSUserDefaults) only in the saveAutoLaunchCheckboxState method,
which then "saves" the new setting by synchronizing the preferences.

That method is invoked by two methods: autoLaunchPrefButtonWasClicked and
shouldSelectTabViewItem.

It makes sense to set/clear the preference in autoLaunchPrefButtonWasClicked --
whenever the user checks or unchecks the box, the new preference should be 
saved.

However, it does not make sense to set/clear the preference in
shouldSelectTabViewItem. shouldSelectTabViewItem sets the preference to the 
current
state of the checkbox. If the "Details" window hasn't been displayed, then the
current state of the checkbox is invalid, so shouldSelectTabViewItem will clear 
the
preference. So the preference will be cleared if the "Details" window hasn't 
been
displayed.

The solution to this problem, then, is to remove the invocation of
saveAutoLaunchCheckboxState from shouldSelectTabViewItem.

The same situation applies to the "Set Nameserver" checkbox. However, the
saveUseNameserverCheckboxState routine is also invoked by the connect and 
disconnect
methods. Again, the preference is set/cleared according to the current state of 
the
checkbox, but if the "Details" window hasn't been opened, the current state of 
the
checkbox is invalid, so connect and disconnect will clear the preference.

===================
To fix the problem:
===================

1. Remove all code from the shouldSelectTabViewItem method.

2. Remove the following lines from the connect method:
    if ([useNameserverCheckbox state] == NSOnState) {
        [self saveUseNameserverCheckboxState:TRUE];
    } else {
        [self saveUseNameserverCheckboxState:FALSE];
    }   

3. Remove the following lines from the disconnect method:
    if ([useNameserverCheckbox state] == NSOnState) {
        [self saveUseNameserverCheckboxState:TRUE];
    } else {
        [self saveUseNameserverCheckboxState:FALSE];
    }

Note that, since the shouldSelectTabViewItem method no longer does anything, 
invoking
it in "cleanup" and "windowShouldClose" is not necessary. These invocations, 
and the
method itself, could be removed from the project.

Original comment by jkbull...@gmail.com on 23 Apr 2009 at 7:51

[GoogleCodeExporter]

I am just a humble user, so could please someone explain to me HOW I can make 
those
changes?
Or could someone give me a corrected file an tell me which one to exchange? (I 
came
as far as 'show package content'...)
Or even better: could the programmers themselves implement those changes in
Tunnelblick and upload a new version? 

That would be great!!
Thanks for the solution anyway!

Original comment by david.se...@googlemail.com on 24 Apr 2009 at 7:06

[GoogleCodeExporter]

(Note to the project's programmers: all the changes I describe in my original 
comment
on this issue are to "MenuController.m".)

I'm sorry that my original comment wasn't clear. These changes must be made by 
one of
the project's programmers. My original comment was really addressed to them --
pointing out what I thought was the problem and a fix for it.

Since this is an open source project, I was able to download the source 
program, look
at it, and modify it for my own use.

I don't want to confuse things by making an unofficial version available, 
especially
when it would be relatively easy for the project's programmers to make these 
changes
officially.

Tunnelblick is is *great* project, and I salute the programmers, but in the 
couple of
months I've been using it the programmers don't seem to be very involved 
anymore, so
I don't know when an official release which fixes this (or any other) problem 
will be
available. I'm new to programming a Mac, so I can do a little, but not much.

Original comment by jkbull...@gmail.com on 24 Apr 2009 at 10:40

[GoogleCodeExporter]

So let's hope that they react this time. Especially if it is really as simple 
as you say.

And I have to agree, that Tunnelblick is GREAT!

Original comment by david.se...@googlemail.com on 24 Apr 2009 at 1:42

[GoogleCodeExporter]

Fixed in trunk as r77.

Original comment by jkbull...@gmail.com on 20 May 2009 at 3:52

• Changed state: Fixed