Closed GoogleCodeExporter closed 8 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
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
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
Issue 185 has been merged into this issue.
Original comment by jkbull...@gmail.com
on 24 Jul 2011 at 1:35
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
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
> 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
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
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
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
> 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
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
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
Thank you for reporting this problem and helping test the "solution".
Original comment by jkbull...@gmail.com
on 26 Jul 2011 at 2:58
[deleted comment]
Comment #3 worked for me.
Original comment by lailo...@gmail.com
on 26 Jul 2011 at 5:52
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:
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:
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
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
> 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
Issue 187 has been merged into this issue.
Original comment by jkbull...@gmail.com
on 31 Jul 2011 at 2:05
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
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
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
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
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:
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
@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
aye, i7 - early mbp 15"
Original comment by gryz...@gmail.com
on 1 Aug 2011 at 6:16
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:
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
[deleted comment]
[deleted comment]
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
I also got it.
Original comment by dimitris.apostolou
on 12 Aug 2011 at 8:13
Attachments:
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
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
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
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
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
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
@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
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
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
@ par.winz...@gmail.com: Thanks. All feedback is helpful!
Original comment by jkbull...@gmail.com
on 25 Aug 2011 at 12:50
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
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
@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
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
Original issue reported on code.google.com by
lailo...@gmail.com
on 22 Jul 2011 at 3:41Attachments: