System Panic on 2011 iMac 27" running Lion

GoogleCodeExporter commented 9 years ago

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:

GoogleCodeExporter commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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:

GoogleCodeExporter commented 9 years ago

Issue 185 has been merged into this issue.

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

GoogleCodeExporter commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

> 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

> 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

Comment #3 worked for me.

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

GoogleCodeExporter commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

> 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 commented 9 years ago

Issue 187 has been merged into this issue.

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

GoogleCodeExporter commented 9 years ago

Apparently, Tunnelblick isn't the only OpenVPN client having this issue.  The 
same issue (with very similar kernel panic logs) is described in another 
(commercial) OpenVPN client's support forums[1], and they also don't seem to 
have a clue about the cause yet.  At least we Tunnelblick users aren't alone 
experiencing this.

I wonder if there's anything in common between the machines crashing because of 
this, that differentiates them from the ones that don't.  Software-wise 
(besides hardware drivers), the only difference between my MBP (not crashing) 
and my iMac (crashing) is VMWare Fusion installed in the latter and missing in 
the former; everything else should be exactly the same, as I usually install 
software in both computers at the same time.

[1]: http://www.thesparklabs.com/forum/viewtopic.php?f=3&t=497&start=10

Original comment by emanuele...@gmail.com on 31 Jul 2011 at 5:41

GoogleCodeExporter commented 9 years ago

I did experience that crash, and I don't have vmware. Just virtual box, but not 
using it during that session at all.

Original comment by gryz...@gmail.com on 31 Jul 2011 at 5:48

GoogleCodeExporter commented 9 years ago

Emanuele - Thanks for the link to Spark Lab's comments about the crashes.

Question: has anyone had the crash who isn't using an i7 processor (that is, 
with OpenVPN 2.1.4 as per comment 3 above)?

I did have one crash with OpenVPN 2.2.1 on an i5 MacBook Pro, but I have not 
been able to reproduce it with OpenVPN 2.1.4 in several hundred 
connection/reconnection cycles.

Original comment by jkbull...@gmail.com on 1 Aug 2011 at 2:50

GoogleCodeExporter commented 9 years ago

Tunnelblick 3.2beta28 contains OpenVPN 2.1.4 and should help most people with 
this issue. It is available by update from earlier 3.2 beta versions, and on 
the Downloads page at 
http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2

Original comment by jkbull...@gmail.com on 1 Aug 2011 at 4:23

GoogleCodeExporter commented 9 years ago

I can confirm that, at least on the 2009 i7 iMac, OpenVPN 2.1.4 doesn't help.  
It took longer (no panics yesterday), but it eventually happened again.

I suspect the Energy Saver-induced sleep (as per Energy Saver system 
preferences) to be one of the triggering causes, as it's happening almost all 
the times I leave the computer unattended for a few hours, while it doesn't 
happen if I press cmd-alt-eject to manually send the computer to sleep.  I'll 
look further into this.

Original comment by emanuele...@gmail.com on 1 Aug 2011 at 11:57

Attachments:

crash.txt

GoogleCodeExporter commented 9 years ago

happened again just now with updated tunnelblick. 

Interval Since Last Panic Report:  47204 sec
Panics Since Last Report:          1
Anonymous UUID:                    9DE7B09C-48AF-4B3A-A223-2818BF688B66

Mon Aug  1 18:50:59 2011
panic(cpu 0 caller 0xffffff80002c268d): Kernel trap at 0xffffff7f807b1c9b, type 
14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000004300000007, CR3: 0x00000001ca61307f, CR4: 
0x00000000000606e0
RAX: 0x0000004300000006, RBX: 0x0000000000000002, RCX: 0xffffff7f807b1c06, RDX: 
0xffffff80145a8b80
RSP: 0xffffff80f2e0b9d0, RBP: 0xffffff80f2e0ba20, RSI: 0x000000008020690c, RDI: 
0xffffff8029923008
R8:  0x0000000000000002, R9:  0x0000000000000000, R10: 0x00007fff6e544e90, R11: 
0xffffff80002d8240
R12: 0x0000000000000066, R13: 0x0000000000000066, R14: 0xffffff8014428c30, R15: 
0xffffff80140b25c8
RFL: 0x0000000000010282, RIP: 0xffffff7f807b1c9b, CS:  0x0000000000000008, SS:  
0x0000000000000010
CR2: 0x0000004300000007, Error code: 0x0000000000000000, Faulting CPU: 0x0

Backtrace (CPU 0), Frame : Return Address
0xffffff80f2e0b690 : 0xffffff8000220702 
0xffffff80f2e0b710 : 0xffffff80002c268d 
0xffffff80f2e0b8b0 : 0xffffff80002d7a3d 
0xffffff80f2e0b8d0 : 0xffffff7f807b1c9b 
0xffffff80f2e0ba20 : 0xffffff7f807b335e 
0xffffff80f2e0ba60 : 0xffffff8000344777 
0xffffff80f2e0bab0 : 0xffffff800039c9fd 
0xffffff80f2e0bb20 : 0xffffff800039e203 
0xffffff80f2e0bcc0 : 0xffffff800033f4b7 
0xffffff80f2e0bd90 : 0xffffff800033f662 
0xffffff80f2e0bdc0 : 0xffffff8000563c3f 
0xffffff80f2e0be00 : 0xffffff8000563ce0 
0xffffff80f2e0be30 : 0xffffff80005312c3 
0xffffff80f2e0be60 : 0xffffff8000560fd4 
0xffffff80f2e0bf50 : 0xffffff80005ca7cb 
0xffffff80f2e0bfb0 : 0xffffff80002d8383 
      Kernel Extensions in backtrace:
         net.tunnelblick.tun(1.0)[576DEDE7-B6C1-610E-B7E4-C54DBDA631AF]@0xffffff7f807b1000->0xffffff7f807b8fff

BSD process name corresponding to current thread: ifconfig
Boot args: -v

Mac OS version:
11A511

Kernel version:
Darwin Kernel Version 11.0.0: Sat Jun 18 12:56:35 PDT 2011; 
root:xnu-1699.22.73~1/RELEASE_X86_64
Kernel UUID: 24CC17EB-30B0-3F6C-907F-1A9B2057AF78
System model name: MacBookPro8,2 (Mac-94245A3940C91C80)

System uptime in nanoseconds: 47362532758865
last loaded kext at 47354097836564: net.tunnelblick.tun 1.0 (addr 
0xffffff7f807b1000, size 32768)
last unloaded kext at 47304942381874: net.tunnelblick.tun   1.0 (addr 
0xffffff7f807a9000, size 24576)
loaded kexts:
net.tunnelblick.tun 1.0
org.virtualbox.kext.VBoxNetAdp  4.0.12
org.virtualbox.kext.VBoxNetFlt  4.0.12
org.virtualbox.kext.VBoxUSB 4.0.12
org.virtualbox.kext.VBoxDrv 4.0.12
com.apple.driver.AppleHWSensor  1.9.4d0
com.apple.filesystems.autofs    3.0
com.apple.driver.AppleMikeyHIDDriver    122
com.apple.driver.AppleUpstreamUserClient    3.5.9
com.apple.driver.AppleMCCSControl   1.0.24
com.apple.driver.AudioAUUC  1.59
com.apple.driver.AppleHDA   2.1.1f11
com.apple.driver.AppleMikeyDriver   2.1.1f11
com.apple.driver.AGPM   100.12.40
com.apple.kext.ATIFramebuffer   7.0.2
com.apple.driver.AppleIntelHDGraphics   7.0.2
com.apple.driver.SMCMotionSensor    3.0.1d2
com.apple.iokit.IOUserEthernet  1.0.0d1
com.apple.Dont_Steal_Mac_OS_X   7.0.0
com.apple.driver.AudioIPCDriver 1.2.0
com.apple.driver.AppleSMCLMU    2.0.1d2
com.apple.driver.ACPI_SMC_PlatformPlugin    4.7.0b2
com.apple.driver.AppleMuxControl    3.0.8
com.apple.driver.AppleLPC   1.5.1
com.apple.ATIRadeonX3000    7.0.2
com.apple.driver.AppleIntelSNBGraphicsFB    7.0.2
com.apple.driver.AppleUSBTCButtons  220.8
com.apple.driver.AppleUSBTCKeyboard 220.8
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless 1.0.0d1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0d1
com.apple.BootCache 32
com.apple.driver.AppleIRController  309
com.apple.iokit.SCSITaskUserClient  3.0.0
com.apple.iokit.IOAHCIBlockStorage  2.0.0
com.apple.driver.AppleUSBHub    4.4.0
com.apple.driver.AirPort.Brcm4331   500.20.6
com.apple.driver.AppleFWOHCI    4.8.6
com.apple.driver.AppleSDXC  1.1.0
com.apple.iokit.AppleBCM5701Ethernet    3.0.6b9
com.apple.driver.AppleSmartBatteryManager   161.0.0
com.apple.driver.AppleAHCIPort  2.1.8
com.apple.driver.AppleUSBEHCI   4.4.0
com.apple.driver.AppleEFINVRAM  1.5.0
com.apple.driver.AppleACPIButtons   1.4
com.apple.driver.AppleRTC   1.4
com.apple.driver.AppleHPET  1.6
com.apple.driver.AppleSMBIOS    1.7
com.apple.driver.AppleACPIEC    1.4
com.apple.driver.AppleAPIC  1.5
com.apple.driver.AppleIntelCPUPowerManagementClient 166.0.0
com.apple.nke.applicationfirewall   3.0.30
com.apple.security.quarantine   1
com.apple.driver.AppleIntelCPUPowerManagement   166.0.0
com.apple.kext.triggers 1.0
com.apple.driver.AppleAVBAudio  1.0.0d11
com.apple.driver.DspFuncLib 2.1.1f11
com.apple.driver.AppleSMBusController   1.0.10d0
com.apple.iokit.IOSurface   80.0
com.apple.iokit.IOBluetoothSerialManager    2.5f17
com.apple.iokit.IOSerialFamily  10.0.5
com.apple.iokit.IOFireWireIP    2.2.3
com.apple.iokit.IOAVBFamily 1.0.0d22
com.apple.iokit.IOAudioFamily   1.8.3fc11
com.apple.kext.OSvKernDSPLib    1.3
com.apple.driver.AppleHDAController 2.1.1f11
com.apple.iokit.IOHDAFamily 2.1.1f11
com.apple.driver.AppleSMC   3.1.1d2
com.apple.driver.IOPlatformPluginFamily 4.7.0b2
com.apple.driver.AppleGraphicsControl   3.0.8
com.apple.driver.AppleSMBusPCI  1.0.10d0
com.apple.driver.AppleBacklightExpert   1.0.3
com.apple.iokit.IONDRVSupport   2.3
com.apple.kext.ATI6000Controller    7.0.2
com.apple.kext.ATISupport   7.0.2
com.apple.iokit.IOGraphicsFamily    2.3
com.apple.driver.AppleThunderboltDPOutAdapter   1.3.2
com.apple.driver.AppleThunderboltDPInAdapter    1.3.2
com.apple.driver.AppleThunderboltDPAdapterFamily    1.3.2
com.apple.driver.AppleThunderboltPCIDownAdapter 1.1.6
com.apple.driver.BroadcomUSBBluetoothHCIController  2.5f17
com.apple.driver.AppleUSBBluetoothHCIController 2.5f17
com.apple.iokit.IOBluetoothFamily   2.5f17
com.apple.driver.AppleUSBMultitouch 220.23
com.apple.driver.CoreStorage    180
com.apple.iokit.IOUSBHIDDriver  4.4.0
com.apple.driver.AppleUSBMergeNub   4.4.0
com.apple.driver.AppleUSBComposite  3.9.0
com.apple.iokit.IOSCSIMultimediaCommandsDevice  3.0.0
com.apple.iokit.IOBDStorageFamily   1.6
com.apple.iokit.IODVDStorageFamily  1.6
com.apple.iokit.IOCDStorageFamily   1.7
com.apple.driver.XsanFilter 403
com.apple.iokit.IOAHCISerialATAPI   2.0.0
com.apple.iokit.IOSCSIArchitectureModelFamily   3.0.0
com.apple.driver.AppleThunderboltNHI    1.2.6
com.apple.iokit.IOThunderboltFamily 1.4.9
com.apple.iokit.IOUSBUserClient 4.4.0
com.apple.iokit.IO80211Family   400.40
com.apple.iokit.IOFireWireFamily    4.4.3
com.apple.iokit.IOEthernetAVBController 1.0.0d5
com.apple.iokit.IONetworkingFamily  2.0
com.apple.iokit.IOAHCIFamily    2.0.6
com.apple.iokit.IOUSBFamily 4.4.0
com.apple.driver.AppleEFIRuntime    1.5.0
com.apple.iokit.IOHIDFamily 1.7.0
com.apple.iokit.IOSMBusFamily   1.1
com.apple.security.sandbox  165
com.apple.kext.AppleMatch   1.0.0d1
com.apple.security.TMSafetyNet  7
com.apple.driver.DiskImages 326
com.apple.iokit.IOStorageFamily 1.7
com.apple.driver.AppleKeyStore  28.18
com.apple.driver.AppleACPIPlatform  1.4
com.apple.iokit.IOPCIFamily 2.6.5
com.apple.iokit.IOACPIFamily    1.4

Original comment by gryz...@gmail.com on 1 Aug 2011 at 5:55

GoogleCodeExporter commented 9 years ago

 @gryz...@gmail.com -- Can you confirm that it is an i7 processor? 

So far, only Lion on i7 processors seem to get this kernel panic.

If anyone else gets a kernel panic (using 3.2beta28), please report it here!

Original comment by jkbull...@gmail.com on 1 Aug 2011 at 6:01

GoogleCodeExporter commented 9 years ago

aye, i7 - early mbp 15"

Original comment by gryz...@gmail.com on 1 Aug 2011 at 6:16

GoogleCodeExporter commented 9 years ago

tunnelblick frequently cause system panic when i wake mbp  from sleep mode. i 
use 3.2beta28 version.
report attached.

Original comment by Cofyc.Ja...@gmail.com on 9 Aug 2011 at 2:02

Attachments:

t.report

GoogleCodeExporter commented 9 years ago

Adding symbols for that next, the panic instruction is

(gdb) x/i 0xffffff7f80854c9b
0xffffff7f80854c9b <tuntap_interface::if_ioctl(unsigned int, 
void*)+149>:    movzbl 0x1(%rax),%edx

Original comment by brian.be...@gmail.com on 10 Aug 2011 at 3:58

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

I can also confirm this is occasionally occurring on my 27" i7 iMac with 10.7 
(Tunnelblick 3.2beta28 (build 2714)). "Monitor Network Settings" is not 
selected. "Set nameserver" is selected.

Original comment by john@johnnowak.com on 11 Aug 2011 at 2:02

GoogleCodeExporter commented 9 years ago

I also got it.

Original comment by dimitris.apostolou on 12 Aug 2011 at 8:13

Attachments:

Kernel_2011-08-12-103004_REX-MacBook-Pro.panic

GoogleCodeExporter commented 9 years ago

I looked more at this...

The panic appears to happen in `tuntap_interface::ifoctl`, specifically in the 
line that reads `if (ifa->ifa_netmask->sa_family != ifa->ifa_addr->sa_family)` 
-- `ifa->ifa_netmask` is known to be non-NULL at this point in the code, but 
apparently it is a garbage ref...

Original comment by davep...@gmail.com on 17 Aug 2011 at 4:37

GoogleCodeExporter commented 9 years ago

I tracked down the bug in tun/tap. 

The problem is that struct ifaddr has changed in OSX Lion. Tun/tap has its own 
definition that is no longer compatible. If tun/tap gets lucky in 
tuntap.cc::876 it will think that ifa->ifa_addr is NULL (probably because it is 
grabbing bytes from the new ifa_debug field) and the "ugly work around" code 
will be skipped. On the other hand, if tun/tap gets unlucky it ultimately 
dereferenes an invalid pointer in tuntap.cc:882.

I will check to see if ifconfig under 10.7 still has a bug with setting the 
sa_family. If so, we'll have to update tun/tap to choose the correct struct 
definition based on the OS version. If the ifconfig bug is fixed in lion then 
we can skip this "work around" code entirely for Lion.

Cheers, 
Dave

Original comment by davep...@gmail.com on 17 Aug 2011 at 9:10

GoogleCodeExporter commented 9 years ago

I've just pushed a preliminary patch to github that fixes tuntap kernel panics 
under Lion.

I have a limited number of machines (and OS variants) to test against, so 
please give this a full and unrelenting beat-down! ;-)

My git repo: https://github.com/davepeck/tuntaposx

The commit itself: 
https://github.com/davepeck/tuntaposx/commit/8afc1066f184f0ebc287eb3712a8fdf4c64
d6706

-Dave

Original comment by davep...@gmail.com on 19 Aug 2011 at 2:25

GoogleCodeExporter commented 9 years ago

Attached is a build, Tunnelblick 3.2beta29 (build 2763) that may help with 
kernel panics on Lion, including panics on computers with i7 processors.

Please try it out and REPORT SUCCESS OR FAILURE ON THIS THREAD.

 It may not help with configurations that are set to connect when the computer starts. If not, please try using it after changing the configuration to connect manually.

This is a build from the current head but with an experimental Tuntap driver 
[1]. (It also has modified bundle identifiers and version numbers in the tun 
and tap kexts, as is usual for Tunnelblick.)

This build includes both OpenVPN 2.1.4 and 2.2.1. The default is to use 2.2.1, 
but 2.1.4 may be selected on the "Preferences" panel of the "VPN Details…" 
window.

[1] 
http://sourceforge.net/tracker/?func=detail&aid=3382978&group_id=235725&atid=109
7639

Original comment by jkbull...@gmail.com on 22 Aug 2011 at 11:33

Attachments:

Tunnelblick_3.2beta29-build-2763.dmg

GoogleCodeExporter commented 9 years ago

I have removed the attached build, and uploaded it to the Tunnelblick 
downloads. It may be accessed at

https://code.google.com/p/tunnelblick/downloads/detail?name=Tunnelblick_3.2beta2
9-build-2763.dmg&can=2&q=

Original comment by jkbull...@gmail.com on 22 Aug 2011 at 12:47

GoogleCodeExporter commented 9 years ago

I posted my problems under 
https://groups.google.com/forum/#!topic/tunnelblick-discuss/nMv0HE0bcJs before 
and now I revert to this discussion. I tried the 3.2betta29 in both versions. 
No success. My internet still gets stuck until I end the Tunnelblick connection 
and I cannot ping any of our servers. I posted my config file and the log file 
yesterday.

Best Regards

Christl

Original comment by christof...@mac.com on 22 Aug 2011 at 3:32

GoogleCodeExporter commented 9 years ago

@christof...@mac.com -- So either there are other problems in Lion (which I 
don't have verifiable reports on) or this is some other problem.

I have unlocked the thread with your problem in case anyone has any other ideas 
for you -- as I posted, it looks like a routing problem to me.

Original comment by jkbull...@gmail.com on 22 Aug 2011 at 3:44

GoogleCodeExporter commented 9 years ago

I have just uploaded a new version, 3.2beta29 (build 2765). It is available at
http://code.google.com/p/tunnelblick/downloads/detail?name=Tunnelblick_3.2beta29
-build-2765.dmg&can=1&q=

Everyone who is experiencing problems on Lion should try this build. It 
includes a fix to Tuntap by the Tuntap author and needs to be tested.

It includes both OpenVPN 2.1.4 and OpenVPN 2.2.1, and defaults to using 2.2.1. 
The selection may be changed on the Preferences panel of the VPN Details… 
window.

Please post success/failure notes on this thread.

Original comment by jkbull...@gmail.com on 24 Aug 2011 at 6:37

GoogleCodeExporter commented 9 years ago

I've had these crashes, and I'm running beta29 now. So far so good after three 
close/opens. I'll let you know!

Original comment by par.winz...@gmail.com on 24 Aug 2011 at 11:34

GoogleCodeExporter commented 9 years ago

@ par.winz...@gmail.com: Thanks. All feedback is helpful!

Original comment by jkbull...@gmail.com on 25 Aug 2011 at 12:50

GoogleCodeExporter commented 9 years ago

Is the tuntap driver included with 3.2beta29 build 2765 some very verbose debug 
build or is it just me?  I'm seeing a really high number of log messages in 
Console (most of them are "tuntap: select. which: 1" or similar), I'm wondering 
if that's an intended behavior.

Everything else looks good.  No crashes yet, using the default OpenVPN 2.2.1 (I 
didn't get any crashes either with build 2763) - at least so far, I'll let you 
know if anything new happens during the next days.

Original comment by emanuele...@gmail.com on 25 Aug 2011 at 6:59

GoogleCodeExporter commented 9 years ago

Dear Jonathan,

the new beta version 3.2beta29 (build 2765) works fine. No problem anymore to 
access the servers, email under Lion. I used the OVPN Version 2.1.4. and 
alternatively 2.2.1.. Both version are fine! I shall keep you posted on further 
developments, if any. Donation coming forward.

Thanks for your help!

Best Christof

Original comment by christof...@mac.com on 25 Aug 2011 at 7:09

GoogleCodeExporter commented 9 years ago

@emmanuele...gmail.com and Christof --
Thanks for your reports. The more we hear, the better we can judge if the 
problem is really fixed. That's difficult with problems like this one that are 
so hard to reproduce. 

@emmanuele...gmail.com --
Yes, it is a special "debug" version that does a lot of extra logging. If there 
is a crash or other misbehavior that would help find the cause. That extra 
logging will be removed from the next version that comes out.

@Everybody --
I included both OpenVPN versions but default to 2.2.1 so that 2.2.1 will be 
tested (since it seemed to aggravate the problem and is a better test that the 
problem is fixed) but everyone would have the option of easily reverting to 
2.1.4 if this build did *not* fix the problem.

As long as 2.2.1 works OK, that is what should be used because that is the 
current stable release of OpenVPN.

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

GoogleCodeExporter commented 9 years ago

I contacted Viscosity guys and they said they fixed this issue by removing the 
"ugly work around" code Dave referred to. According to them the removed block 
is only needed on 10.4 and older version of OS X, which Viscosity does not 
support anyways.

Original comment by samuli.s...@gmail.com on 25 Aug 2011 at 12:31

gco / tunnelblick

System Panic on 2011 iMac 27" running Lion #186