Tunnelblick disconnects on configuration directory listing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Connect with Tunnelblick to a OpenVPN server
2. cd ~/Library/
3. ls openvpn/

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

Expected is that Tunnelblick stays connected, but Tunnelblick closes the
connection.

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

I am using 3.0b10, on 10.5.5, Intel.

Please provide any additional information below.

I have this problem when I am backuping my home directory as backup program
traverses file hierarchy and disconnects OpenVPN session. The same happens
if I use find over a home directory.

Original issue reported on code.google.com by mmi...@gmail.com on 21 Nov 2008 at 2:38

[GoogleCodeExporter]

Original comment by angelol...@gmail.com on 21 Nov 2008 at 7:53

• Changed state: Accepted

[GoogleCodeExporter]

I am using 3.0b10, on 10.5.6, Intel.

Same problem, also have a (hourly) backup running.

Openvpn exits with following error:
Fri Jan 30 13:23:18 2009 us=247349 event_wait : Interrupted system call (code=4)

Original comment by rhaasjes@gmail.com on 30 Jan 2009 at 12:26

[GoogleCodeExporter]

I have reported this problem earlier as well. It can be reproduced -almost- 
every time by doing a reasonably 
lengthy disk-intensive action from the console, like traversing a filesystem 
with 'find' or doing a disk-usage 
calculation with 'du' on a full filesystem, f.e.:

find / -name *.lproj

or

du -sh /*

These typical actions have caused Tunnelblick to disconnect on me more than a 
dozen times. I'm no 
programmer wiz, but a guess would be that Tunnelblick sits with very low 
priority, and something intensive 
as a long session of find/du causes Tunnelblick to, uh, "time out" the 
connection and just drop it silently.

This problem has been present since an early 3.0-beta, both under Tiger and 
Leopard, and is currently 
present in 3.0b10 as well. I'm currently running 10.5.6.

Original comment by dji...@gmail.com on 7 Feb 2009 at 1:37

[GoogleCodeExporter]

No, I doubt that it is a load issue as I am doing much more intensive tasks on 
my
computer and Tunnelblick does not disconnect. As you can see in my initial 
report it
is enough just to do a listing on Tunnelblick (OpenVPN) configuration 
directory.Bboth
du and find do traverse filesystems and also do enter and list a Tunnelblick
configuration directory. This is the reason why find, du, backup and other 
utilities
disconnect Tunnelblick - they traverse its configuration directory.

Tunnelblick is probably in some way probably checking access time on a 
directory or
have some other similar hook which gets triggered when you traverse the 
directory.
This is probably meant so that if you would add a new configuration directory
Tunnelblick would add it to the list of available configurations. It is only too
sensitive. And it also disconnects connections instead of just adding a new
configuration (when there is new).

Original comment by mmi...@gmail.com on 7 Feb 2009 at 9:32

[GoogleCodeExporter]

I have been having a problem I believe is related to this.
OSX 10.5.6 Intel MacBook4,1
Tunnelblick 3.0b10
Backblaze 1.0.0.134 ( backblaze.com )

My tunnelblick was working perfectly for 6 months until I installed the tool 
for backblaze online backups. It 
has a launch daemon which always watching for modified files and backing them 
up as needed. After 
installing this my tunnel drops out randomly - after anything from 5 minutes to 
4 hours.

It does not seem to be a bandwidth issue as It happened when there was little 
or no new content I would 
expect to be backed up, Backblaze has a network niceness slider which I turned 
down and tunnelblick never 
dropped out when I did things that really did tax my connection.

I could not replicate the effect using find or ls as above.

I could stop the dropouts by unloading the backblaze launch daemon and killing 
any bb related processes. I 
ran without bb for a week with no dropouts but turning it on again has brought 
them back.

The dropout is very sudden - there is no slow timeout - the connecting is fine 
and then suddenly gone. Here 
are all the log messages from the time when a disconnection occurred. I checked 
other system log files and 
could not find any other events that occur at the same time as the dropouts.

Mon May  4 20:17:22 2009 event_wait : Interrupted system call (code=4)
Mon May  4 20:17:22 2009 TCP/UDP: Closing socket
Mon May  4 20:17:22 2009 Closing TUN/TAP interface
Mon May  4 20:17:22 2009 SIGTERM[hard,] received, process exiting
Mon May  4 20:17:22 2009 MANAGEMENT: >STATE:1241432242,EXITING,SIGTERM,,

Backblaze does have a free trial - if you can't reproduce the items above maybe 
try running backblaze for a 
day?

Original comment by caf...@gmail.com on 4 May 2009 at 1:56

[GoogleCodeExporter]

On further thought I realised that - for me at least - this issue would go from 
a major annoyance to a minor blip 
if tunnelblick would at least reconnect automatically after one of these 
"Interrupted system call" errors.

It is frustrating that more often than not when I do something on the VPN I 
realise it has been disconnected and 
have to click on the tunnelblick icon and ask it to reconnect then wait till it 
is ready.

Perhaps it would also need a feature to detect if reconnections were happening 
too rapidly and to then add a 
standoff time.

Original comment by caf...@gmail.com on 4 Jun 2009 at 1:44

[GoogleCodeExporter]

Fixed in trunk as r99.

Note that all connections will be disconnected if configuration files (.ovpn or 
.conf files in ~/Library/openvpn) 
are changed/added/deleted.

Original comment by jkbull...@gmail.com on 22 Jul 2009 at 3:47

• Changed state: Fixed

[GoogleCodeExporter]

Hi,

I'm using Tunnelblick 3.0b28 (mac os 10.6.2, Intel 32) and i've some trouble 
with it.
Tunnelblick connect to my distant vpn normally (IPCop with Zerina 0.9.5b), and 
after
few seconds, it disconnect. The log:

"
2010-02-26 17:29:28 /sbin/route add -net 109.209.68.134 192.168.36.1 
255.255.255.255
2010-02-26 17:29:28 /sbin/route add -net 0.0.0.0 10.62.253.5 128.0.0.0
2010-02-26 17:29:28 /sbin/route add -net 128.0.0.0 10.62.253.5 128.0.0.0
2010-02-26 17:29:28 
2010-02-26 17:29:28 /sbin/route add -net 192.168.4.0 10.62.253.5 255.255.255.0
2010-02-26 17:29:28 /sbin/route add -net 10.62.253.1 10.62.253.5 255.255.255.255
2010-02-26 17:29:28 Initialization Sequence Completed
2010-02-26 17:29:28 109.209.68.134
2010-02-26 17:29:34 event_wait : Interrupted system call (code=4)
2010-02-26 17:29:34 TCP/UDP: Closing socket
2010-02-26 17:29:34 /sbin/route delete -net 10.62.253.1 10.62.253.5 
255.255.255.255
2010-02-26 17:29:34 /sbin/route delete -net 192.168.4.0 10.62.253.5 
255.255.255.0
2010-02-26 17:29:34 /sbin/route delete -net 109.209.68.134 192.168.36.1 
255.255.255.255
2010-02-26 17:29:34 /sbin/route delete -net 0.0.0.0 10.62.253.5 128.0.0.0
2010-02-26 17:29:34 /sbin/route delete -net 128.0.0.0 10.62.253.5 128.0.0.0
2010-02-26 17:29:34 Closing TUN/TAP interface
2010-02-26 17:29:34
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh tun0 1400 
1442
10.62.253.6 10.62.253.5 init
2010-02-26 17:29:34  process restarting
2010-02-26 17:29:34 
2010-02-26 17:29:34 MANAGEMENT: CMD 'hold release'
2010-02-26 17:29:34 SUCCESS: hold release succeeded
"

the line "2010-02-26 17:29:34 event_wait : Interrupted system call (code=4)" 
isn't
normal i think, no?

A precision, my account is provided by an Active Directory on my Mac. I've
experimented some trouble with other program (like Adobe CS installation's 
software),
and the cause was the AD account system.

Thanks you.

Original comment by jlien...@gmail.com on 26 Feb 2010 at 4:36

[GoogleCodeExporter]

jlienard, I don't think your problem is this Issue because there is no evidence 
that the configuration directory 
is being accessed.

You are correct that the problem is shown by the "Interrupted system call" 
message, which usually means that 
the openvpn process that maintains the connection is being terminated.

Is there anything in the Console Log that shows why the openvpn process is 
being terminated?

Is this a new problem with Tunnelblick 3.0b28, and an earlier version of 
Tunnelblick works? If so, which one?

Original comment by jkbull...@gmail.com on 27 Feb 2010 at 8:59

[GoogleCodeExporter]

I have exactly the same issue with version 3.1.5...

Original comment by ln...@connectiv-it.com on 15 Feb 2011 at 10:16

[GoogleCodeExporter]

"exactly the same" as what? As this issue (Disconnect on configuration 
directory listing?

Original comment by jkbull...@gmail.com on 15 Feb 2011 at 10:25