System Panic on 2011 iMac 27" running Lion

[GoogleCodeExporter]

NOTE: We suggest that you post on the Tunnelblick Discussion Group before
submitting an "Issue". (http://groups.google.com/group/tunnelblick-discuss)

What steps will reproduce the problem?
1. Repeatedly Connecting on 27" iMac 2011
2.
3.

What is the expected output?

What do you see instead?
System Crash

What version of Tunnelblick are you using? On what version of OS X?
Latest Beta

Please provide any additional information below. Please include your
configuration file and the contents of the OpenVPN Log window (including
the first few lines with version information), but remember to remove any
sensitive information such as IP addresses.

I've installed Lion on both an old Macbook Pro and a new iMac 27" (same latest 
beta Tunnelblick and identical configuration files)

On the 2009 Macbook Pro it worked. (I have VMWare installed)

On the iMac it kept disconnecting and reconnecting and then suddenly my mac 
crashed (log showed it crashed in program : ifconfig) (I also have VMWare but 
additionally Parallels)

Original issue reported on code.google.com by lailo...@gmail.com on 22 Jul 2011 at 3:41

Attachments:

• crash.txt
• EULabsSA.conf

[GoogleCodeExporter]

PS: Relevant discussion forum thread:

https://groups.google.com/forum/#!topic/tunnelblick-discuss/SLELHKszbSo

Original comment by lailo...@gmail.com on 22 Jul 2011 at 3:52

[GoogleCodeExporter]

Just to confirm, my version is: 3.2beta26 (build 2687) OpenVPN 2.2.1

(It would have been nice if I could actually copy and paste this text from the 
Info Tab....)

Original comment by lailo...@gmail.com on 22 Jul 2011 at 3:55

[GoogleCodeExporter]

Another problem has come up that was traced to OpenVPN 2.2.1 (which this 
version of Tunnelblick uses).

Can you put the two openvpn files I've attached into 
Tunnelblick.app/Contents/Resources and see if that makes any difference? (Or 
copy them from an old version of Tunnelblick 3.1.7 if you are nervous about it.)

(Make a backup copy of Tunnelblick.app first).

To get Tunnelblick.app/Contents/ in a Finder window, Command-click 
Tunnelblick.app (not an alias to it) and select "Show Package Contents".

Original comment by jkbull...@gmail.com on 22 Jul 2011 at 4:43

Attachments:

• openvpn
• openvpn-down-root.so

[GoogleCodeExporter]

Issue 185 has been merged into this issue.

Original comment by jkbull...@gmail.com on 24 Jul 2011 at 1:35

[GoogleCodeExporter]

Ok, so I did:

thor:Downloads marius$ sudo cp openvpn openvpn-down-root.so 
/Applications/Tunnelblick.app/Contents/Resources/

(While it was running but not connected/connecting, I hope this was ok)

Still the same, It goes into a loop of connecting and disconnecting. But unlike 
previously where it did this about 8-10 times before crashing, this time it did 
not crash.

But I'm not sure if that is any true test.

Original comment by lailo...@gmail.com on 24 Jul 2011 at 11:02

[GoogleCodeExporter]

Seems to be:

Kernel Extensions in backtrace:
net.tunnelblick.tun(1.0)[576DEDE7-B6C1-610E-B7E4-C54DBDA631AF]@0xffffff7f8092f00
0->0xffffff7f80936fff

in the tun/tap driver, dunno if this is part of OpenVPN or Tunnelblick?

Original comment by lailo...@gmail.com on 24 Jul 2011 at 11:04

[GoogleCodeExporter]

> Still the same, It goes into a loop of connecting and disconnecting.
> But unlike previously where it did this about 8-10 times before crashing,
> this time it did not crash.

That's very interesting. The crash (I assume you mean the kernel panic) is very 
important since the result is so catastrophic. But if it only happens with 
OpenVPN 2.2.1, we can go back to 2.1.4. Your experience seems to support that.

The looping is probably something completely different (I assume you have 
"Monitor network settings" checked. If you uncheck it the looping should stop.

Of course, the looping is a problem, too, but I have seen it before (if it is 
what I am thinking of.) I suspect that is a problem with the "Monitor network 
settings" feature -- the script that does this is not terribly intelligent 
about what changes warrant a restart of the connection.

Since it isn't crashing, can you post the Tunnelblick log (with the patched 
openvpn/openvpn-down-root.so and with "Monitor network settings" checked)? The 
log might show what the script needs to be more intelligent about. Thanks in 
advance.

Original comment by jkbull...@gmail.com on 24 Jul 2011 at 11:23

[GoogleCodeExporter]

yes, the kernel oopsie. Had a few of these back in the day I was developing on 
Linux device drivers, also had probably more on Mac OS X do far than on Vista 
or Windows 7... how times change.

The "Monitor Network Settings" is off, yet it automatically disconnects about 
5-10 seconds after connecting and then starts re-connecting again automatically.

Thus it may not be related to this setting (perhaps the app openvpn app crashes 
rather than a dropped connection?)

Original comment by lailo...@gmail.com on 24 Jul 2011 at 11:33

[GoogleCodeExporter]

Ok, so I've run the app for a while now and still no panic. Perhaps it only 
happens with some specific conditions? Network load? Bus Load? Or considering 
some of the issues regarding threaded code and concurrency issues with SMP it 
may have something to do with the new kernel/driver and the i7 quad core I have?

Original comment by lailo...@gmail.com on 24 Jul 2011 at 11:35

[GoogleCodeExporter]

Please post the log without "Monitor connection" checked -- it should show 
_why_ OpenVPN is restarting all by itself. (verb 3 or higher in the OpenVPN 
config file is usually enough to show the reason.)

And to answer your question, tun/tap is neither OpenVPN not Tunnelblick! (It is 
an independent project (http://tuntaposx.sourceforge.net).

Original comment by jkbull...@gmail.com on 24 Jul 2011 at 11:40

[GoogleCodeExporter]

> Ok, so I've run the app for a while now and still no panic.

You mean with the patched openvpn/openvpn-downroot.so?

It definitely happens only sometimes to me -- once, actually. In several score 
of connect/disconnect cycles over several hours. I only have a two-core i5, 
though.

Original comment by jkbull...@gmail.com on 24 Jul 2011 at 11:44

[GoogleCodeExporter]

I will do so this evening. I am at work now and have found that they have 
changed the VPN settings today, so will have to update these as well before I 
can test.

PS: We have set our VPN to allow multiple simultaneous connections from a 
single user, and my work machine was connected the whole weekend. I just want 
to confirm that this was not the reason I was being disconnected constantly at 
home, will confirm this tonight as well. (it would be great if this was the 
problem for me, although I was assured by my sysadmin that the server is not 
configured to log me off)

Original comment by lailo...@gmail.com on 25 Jul 2011 at 3:26

[GoogleCodeExporter]

Ok, so in addition to no more crashes happening, it seems that the disconnect 
and reconnecting was an artifact of my two computers vying for a single 
connection slot on the server. And each one disconnected the other. (I had left 
work on Thursday with my VPN connection active, had it running the entire 
week-end)

It would seem (counter to what my system admin says for which I will take them 
to task) that I was limited to a single connection which led to my disconnects. 
(I will still make 100% sure of this)

However it was useful in actually exposing the kernel panic bug originally, 
which I *seem* to have fixed now with the older OpenVPN binaries provided.

Thanks Jonathan!

Original comment by lailo...@gmail.com on 25 Jul 2011 at 9:33

[GoogleCodeExporter]

Thank you for reporting this problem and helping test the "solution".

Original comment by jkbull...@gmail.com on 26 Jul 2011 at 2:58

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Comment #3 worked for me.

Original comment by lailo...@gmail.com on 26 Jul 2011 at 5:52

[GoogleCodeExporter]

The late 2009 iMac model seems to be affected as well, this is the fourth 
kernel panic I get in a few days after upgrading to Lion.  The computer is, 
again, the top-of-line i7 model.

I'll try now what suggested in comment #3, but even with the current beta I 
tried to manually disconnect and reconnect several times, and it didn't trigger 
the panic, so I'm not sure on how to really test it, besides having it run for 
some days.

If it may help, the crash usually happens when I leave the computer unattended 
for some hours (and I suspect openvpn reconnecting for some reason, most likely 
a sleep/wakeup event).  It also once happened right after logging in after a 
reboot, as soon as the Tunnelblick icon transitioned from the disconnected to 
the connecting state.

Original comment by emanuele...@gmail.com on 30 Jul 2011 at 5:10

Attachments:

• crash.txt

[GoogleCodeExporter]

In reference to comment #17 I just posted, that didn't seem to help: I got 
another kernel panic right away.

This is what I did:
- Disconnect my openvpn connection through the Tunnelblick menu
- Quit Tunnelblick
- Replace the two files inside the app bundle, as per comment #3
- Restart Tunnelblick and type my admin password in order to let it do its 
chmod/chown magic
- Wither with fear at the sight of my screen going darker and showing me yet 
another kernel panic notification.

Crash log seems to be pretty much the same as the previous one.

On a side note, the suggestion to uncheck "Monitor network settings" doesn't 
seem to be applicable here, as the checkbox is disabled (and shown as unchecked 
anyways).

Original comment by emanuele...@gmail.com on 30 Jul 2011 at 5:25

Attachments:

• crash2.txt

[GoogleCodeExporter]

Thanks for both of your comments. I still can't reproduce this (on an early 
2011 MacBook Pro).

> "the suggestion to uncheck "Monitor network settings" doesn't seem to be 
applicable here"

You are apparently not using either "Do not set nameserver" or "Set 
nameserver", but are using something else, like "Set nameserver (3.1)"

Or are you using your own up/down scripts?

That could be the problem. Each of the behaviors (except "Do not set 
nameserver") is controlled by a script; the setting determines which script. 
Perhaps some of the older scripts are not compatible with Lion.

Please try setting it to "Do not set nameserver" or "Set nameserver" (or both) 
and see if that helps. (If you can stand risking the kernel panic again!)

Original comment by jkbull...@gmail.com on 30 Jul 2011 at 5:44

[GoogleCodeExporter]

Rats, I forgot that "Do not set nameserver" doesn't allow "Monitor network 
settings" to be checked, either, so that's probably what you have. If that's 
the case, don't bother to test "Set nameserver". Sorry.

Original comment by jkbull...@gmail.com on 30 Jul 2011 at 5:54

[GoogleCodeExporter]

> Thanks for both of your comments. I still can't reproduce this (on an early 
2011 MacBook Pro).

Yes, I can confirm this, the issue doesn't seem to happen at all on my early 
2011 MBP either (13" dual core i5). At least so far.

> Rats, I forgot that "Do not set nameserver" doesn't allow "Monitor network 
settings" to be checked, either, so that's probably what you have. If that's 
the case, don't bother to test "Set nameserver". Sorry.

Oh, that's right. I'm using the "Do not set nameserver option", as I don't 
route my traffic through the VPN nor the VPN server shares any nameserver 
setting (I just use it to connect to my server when I'm on the move).

Original comment by emanuele...@gmail.com on 30 Jul 2011 at 5:59

[GoogleCodeExporter]

Issue 187 has been merged into this issue.

Original comment by jkbull...@gmail.com on 31 Jul 2011 at 2:05