disconnect every 5-10 seconds - event_wait : Interrupted system call (code=4)

[Muckman]

Hi everyone,

I've been using Tunnelblick in a very old version from 31. March 2007.
Worked fine all the time.
Now I updated to 3.0b16. (i'm using OSX 10.5.8)

Now the connection drops every 5-10 seconds with "event_wait :
Interrupted system call (code=4)" and immediate reconnect.

Any Idea?

kind regards,
mike

[Muckman]

Update:
With 3.0b10 there is no problem.

[walker333]

Same thing here. The strange thing is that I use two different ovpn
servers. I have no problem with one of them and I have the same above
problem with the other. I can provide configuration files and result
logs If needed.
Please note that I had no problems with version b12 also. The
problems
appeared with version b14 and continued with version b16.
Best regards,
Dimitris

[jkbull...gmail.com]

The changes from b12 to b14 were minor, so we should be able to find
out what's happening.

It would be helpful if you could post (just copy/paste into a
response) the config files for both the connection that works and the
one that doesn't.

Also:
* Do you (usually) only connect to one VPN at a time?
* Do you make any changes to your network setup (or anything else on
your computer) to connect with one or the other VPN server?
* Is your network setup using DHCP only, or do you have any manual
settings?
* Tiger or Leopard? Intel or PPC?

Thanks!

[Muckman]

OSX 10.5.8 - Intel

Maybe the problem resides in the MTU Size - this is the only non
standard value.

* only 1 connection at a time
* no chages to network setup

conf:
#OpenVPN Server conf
tls-client
client
dev tun
proto udp
tun-mtu 1300
remote a.b.c.d 1194
pkcs12 secret.p12
cipher BF-CBC
comp-lzo
verb 3
ns-cert-type server

[jkbull...gmail.com]

Thanks for your quick reply. I have separately emailed you a special
version of Tunnelblick to try, if you would.

[walker333]

The config with the server that works is:

client
dev tap0
proto udp
remote my-server 1978
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
pkcs12 my.key.p12
comp-lzo
verb 3
tls-remote OVPN-SERVER

and the config with the server that has problem is:

client
dev tun
proto tcp
remote my.server-2 443
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo no
verb 3
auth-user-pass
ca cacert.crt
ca ROOT-MY-cacert.crt
script-security 3
------------------------------------------------------
one server at a time,
no changes from my side,
DHCP only
Leopard Intel.

I hope it is usefull to you.

Best regards,
Dimitris

[jkbull...gmail.com]

Thanks, walker333. Can you confirm that Tunnelblick 3.0b12 works, but
3.0b14 doesn't? That would be really helpful.

Thanks again.

[Muckman]

Hi,

try to uncheck "set nameserver" in the connection details - for me
this solved the problem.

kind regards,
mike

[walker333]

Mike,

yes you are right. That explains also why I don't have problems with
one of my two vpn servers, because I don't use the "set nameserver"
option with it.

Best regards,
Dimitris

[Muckman]

in the current svn the problem is allready solved.

i've published the built app at http://www.novon.org/download/Tunnelblick.app.zip
so you do not need to install xcode.

all the best,
mike

[jkbull...gmail.com]

Thanks for your work, Mike, but a build from the head of the svn trunk
should be identical to 3.0b16 except for the build and version
numbers. Nothing has changed in the trunk since 3.0b16 was created
except the version and build numbers.

Did you build a "debug" version or use other non-standard build
options? That could make a difference.

On Aug 23, 3:25 pm, Muckman <muck...@reflex.at> wrote:
> in the current svn the problem is allready solved.
>

> i've published the built app athttp://www.novon.org/download/Tunnelblick.app.zip

[Muckman]

ok - the difference is not in the build but in the network
configuration.

i've removed and added ServerAdresses in scutil several times while
searching for the bug. The problem must be somewhere in the
configuration.
now b16 also works.

It's not the build but any change within scutil.

all the best,
mike

[Muckman]

i've tracked down the problem.

when you have an additional dns server configured in the network
preferences with DHCP b12-b16 doesn't work.

when scutil get State:/Network/Global/DNS returns more than 1 entry
then b12-b16 will crash.

You have to correct leasewatch.
i've commented out #kill -USR1 ${PROCESS} and now b17 works also with
more than one serveradresses.

kind regards,
mike

[Diego Rivera]

The main problem here is one of supported DNS features and unsupported
ones. When you manually configure DNS's, MacOSX forces them to be
used in preference to any automatically-obtained DNS's (i.e. via
DHCP). This makes sense in some scenarios. However, if that is the
case, then it makes absolutely no sense for you to want to obtain DNS
servers from the VPN for your use, since your manually-configured ones
will be used for everything - except when splitting DNS as supported
by MacOSX (which, btw is NOT supported by those scripts).

Thus, your problem isn't so much Tunnelblick and its scripts. Your
problem is more towards the DNS architecture you're trying to
implement. Even if we altered the scripts to support the
*aggregation* of configurations (i.e. pre-pend manually-configured
name servers to those obtained from OpenVPN), the net result would be
the same as if you weren't using the "Set Nameserver" flag at all -
which you yourself acknowledge to be the fix for the problem.

Having babbled on enough about the whyfors and wheretos... can you
explain *why* it is you're configuring your DNS's statically and why
you would seek to achieve the aggregation of those statically-
configured DNS's with the OpenVPN ones? In short - what is the
functionality you're seeking to attain by that?

Maybe this will help figure out what the optimal solution is here.

Cheers.

[Diego Rivera]

Thinking about this a little more this only makes sense in cases where
your manually-configured DNS would somehow become inaccessible once
the OpenVPN link is up (i.e. is not in your local subnet, and you're
using the OpenVPN link as your default gateway, and that DNS isn't
accessible via that route, for instance - other scenarios are
possible). That way the configuration can stay, but the
"fallback" (secondary, whatever you want to call them) nameservers are
used (i.e. the ones that OpenVPN provided Tunnelblick) since the
primary (or primaries, however the case may be) won't be accessible.

Needless to say this will provide a somewhat lousy user experience as
any lookup will have to wait until the resolver times out while
attempting to contact each of the DNS's in turn until it reaches the
ones provided by OpenVPN which, presumably, would be accessible.

Again - it will help tremendously if you try to explain exactly what
you're trying to accomplish here so we can factor all that in.

[Muckman]

It's the combination of DSL Router and my provider - who had some time
ago problems with his DNSs.
I cannot easily set DNS Servers manually in the DSL routers DHCP
server, therefore i've set up additional DNSs on the Mac, becaus the
provider's one where buggy.

Now i could configure 3 more DNS for each VPN i want to connect to,
but this would result in poor rsolve times whenever i'm not connected
to all the VPNs.

[Diego Rivera]

Your main problem is that you're trying to solve one problem by creating another.  If you manually configure your DNS's, then they will override those configured by the VPN (unless, as I mentioned, for some reason those manually configured nameservers become inaccessible when the VPN is active).  Thus, you won't be able to make use of your VPN DNS servers and as such, why would you want to use "Set Nameserver" anyway?

We've already cooked up an updated script for this (attached).  You can try it by copying it (as root) into /Applications/Tunnelblick.app/Contents/Resources.  This supports manually-configured DNS settings (both nameservers and search domains), but it doesn't support changing those configurations on-the-fly with the tunnel up (yet...that will take some work to support, though).

Try that, and let us know if it helps.

I would also suggest speaking to your ISP regarding their DNS issues - after all, this is crucial for your internet link to be functional and if they can't provide reliable name resolution, then you're probably better off with another ISP... unless, of course, you don't have a choice...

Anyway - try the script and see if it helps.

Cheers.

Muckman wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

--

Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

[peisch]

The above new-client-up.tar.gz fixes my DHCP system, but it doesn't
fix my static config. I guess I can make the static config system use
DHCP instead? I'd prefer it be static though...

(thanks for this cool client!)

[Diego Rivera]

What do you mean by "...it doesn't fix my static config..."?  The script is designed to co-exist with a static config.  In reality, and for many (if not most) scenarios, you actually want to use DHCP to take one more configuration item out of your hair.  You should only mess with manual configurations if you either a) know exactly what you're doing, or b) have no other choice.

Anyway - please describe the above so we can help you figure this out.

Cheers.

peisch wrote:

The above new-client-up.tar.gz fixes my DHCP system, but it doesn't
fix my static config.  I guess I can make the static config system use
DHCP instead?  I'd prefer it be static though...

(thanks for this cool client!)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

[swa66]

Glad to have found this.

I had indeed added a fixed DNS server for the airport interface while
on a trip (where the hotel's DHCP server didn't assign any DNS server
for some reason).

I fail to see the reason for persisting a behavior where the
connection is built up and broken down and only a rather obscure
message is logged.

So I'd suggest to
- log the problem clearly: "you have configured a fixed DNS server"
- not build up and break down the connection in an endless loop
(there's nothing useful in doing that)
- override the DNS settings while the conection is up and restore them
afterwards.

I honestly fail to see why -for a VPN where the administrator attracts
DNS resolution to a central server- there should be any importance at
all to what the DNS server settings were prior to the connection being
brought up, let alone how they were established. The purpose of the
setign is to override local settings, no matter how they came to be or
why they are.

As it is now:
- obscure error message at best, not even hinting at the real problem
at all
- endless loop of building and breaking the connection
it's about the worst possible user experience.

SWA

[Diego Rivera]

This behavior has already been corrected.  Not sure when the release will be made.  Can somebody confirm if 3b14 or 3b16 (or which) release has the fix for this?

Thanks!

swa66 wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

[Swa Frantzen]

FWIW: I am using 3.0b16 build 575.

SWA

[jkbull...gmail.com]

If you are talking about Diego's scripts of August 22, they were
commited as r160 on August 25.

They are not in a release yet; 3.0b16 was released on August 22.

Note that the scripts were updated in r183 on September 8 to support
WINS configuration gotten from the OpenVPN server. The r183 scripts
will be in the next release, which I expect will be by the end of this
month.

On Sep 22, 7:44 am, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> This behavior has already been corrected.  Not sure when the release will be made.  Can somebody confirm if 3b14 or 3b16 (or which) release has the fix for this?
> Thanks!

> swa66 wrote:Glad to have found this. I had indeed added a fixed DNS server for the airport interface while on a trip (where the hotel's DHCP server didn't assign any DNS server for some reason). I fail to see the reason for persisting a behavior where the connection is built up and broken down and only a rather obscure message is logged. So I'd suggest to - log the problem clearly: "you have configured a fixed DNS server" - not build up and break down the connection in an endless loop (there's nothing useful in doing that) - override the DNS settings while the conection is up and restore them afterwards. I honestly fail to see why -for a VPN where the administrator attracts DNS resolution to a central server- there should be any importance at all to what the DNS server settings were prior to the connection being brought up, let alone how they were established. The purpose of the setign is to override local settings, no matter how they came to be or why they are. As it is now: - obscure error message at best, not even hinting at the real problem at all - endless loop of building and breaking the connection it's about the worst possible user experience. SWA On Aug 24, 5:56 am, Diego Rivera<diego.riv...@rbxglobal.com>wrote:Thinking about this a little more this only makes sense in cases where your manually-configured DNS would somehow become inaccessible once the OpenVPN link is up (i.e. is not in your local subnet, and you're using the OpenVPN link as your default gateway, and that DNS isn't accessible via that route, for instance - other scenarios are possible).  That way the configuration can stay, but the "fallback" (secondary, whatever you want to call them) nameservers are used (i.e. the ones that OpenVPN provided Tunnelblick) since the primary (or primaries, however the case may be) won't be accessible. Needless to say this will provide a somewhat lousy user experience as any lookup will have to wait until the resolver times out while attempting to contact each of the DNS's in turn until it reaches the ones provided by OpenVPN which, presumably, would be accessible. Again - it will help tremendously if you try to explain exactly what you're trying to accomplish here so we can factor all that in.> Director / System Operations

> Roundbox Global :enterprise : technology : genius
> ------------------------------------------------------------------------------------------------------------------
> Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
> email:diego....@rbxglobal.com|www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>

>  signature.asc
> < 1KViewDownload

[Diego Rivera]

However, you have to take into account that using manual DNS's will, in general, take a dump on any DNS configuration you might later obtain from the OpenVPN server because of how DNS works.  The only way around this is to use Mac's "zoned DNS" approach where you can specify which DNS will be used to resolve which names.  This is a wholly manual approach, however, and it's also important to note that if this is going to be the case, then using "Set Nameserver" doesn't make a whole lot of sense anyway.

Cheers.

jkbull...gmail.com wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

--

Diego Rivera

[jkbull...gmail.com]

A new release is out that includes the scripts as updated in r183.

On Sep 22, 4:16 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> However, you have to take into account that using manual DNS's will, in general, take a dump on any DNS configuration you might later obtain from the OpenVPN server because of how DNS works.  The only way around this is to use Mac's "zoned DNS" approach where you can specify which DNS will be used to resolve which names.  This is a wholly manual approach, however, and it's also important to note that if this is going to be the case, then using "Set Nameserver" doesn't make a whole lot of sense anyway.
> Cheers.

> jkbull...gmail.com wrote:If you are talking about Diego's scripts of August 22, they were commited as r160 on August 25. They are not in a release yet; 3.0b16 was released on August 22. Note that the scripts were updated in r183 on September 8 to support WINS configuration gotten from the OpenVPN server. The r183 scripts will be in the next release, which I expect will be by the end of this month. On Sep 22, 7:44 am, Diego Rivera<diego.riv...@rbxglobal.com>wrote:This behavior has already been corrected.  Not sure when the release will be made.  Can somebody confirm if 3b14 or 3b16 (or which) release has the fix for this? Thanks! swa66 wrote:Glad to have found this. I had indeed added a fixed DNS server for the airport interface while on a trip (where the hotel's DHCP server didn't assign any DNS server for some reason). I fail to see the reason for persisting a behavior where the connection is built up and broken down and only a rather obscure message is logged. So I'd suggest to - log the problem clearly: "you have configured a fixed DNS server" - not build up and break down the connection in an endless loop (there's nothing useful in doing that) - override the DNS settings while the conection is up and restore them afterwards. I honestly fail to see why -for a VPN where the administrator attracts DNS resolution to a central server- there should be any importance at all to what the DNS server settings were prior to the connection being brought up, let alone how they were established. The purpose of the setign is to override local settings, no matter how they came to be or why they are. As it is now: - obscure error message at best, not even hinting at the real problem at all - endless loop of building and breaking the connection it's about the worst possible user experience. SWA On Aug 24, 5:56 am, Diego Rivera<diego.riv...@rbxglobal.com>wrote:Thinking about this a little more this only makes sense in cases where your manually-configured DNS would somehow become inaccessible once the OpenVPN link is up (i.e. is not in your local subnet, and you're using the OpenVPN link as your default gateway, and that DNS isn't accessible via that route, for instance - other scenarios are possible).  That way the configuration can stay, but the "fallback" (secondary, whatever you want to call them) nameservers are used (i.e. the ones that OpenVPN provided Tunnelblick) since the primary (or primaries, however the case may be) won't be accessible. Needless to say this will provide a somewhat lo usy user experience as any lookup will have to wait until the resolver times out while attempting to contact each of the DNS's in turn until it reaches the ones provided by OpenVPN which, presumably, would be accessible. Again - it will help tremendously if you try to explain exactly what you're trying to accomplish here so we can factor all that in.> Director / System Operations Roundbox Global :enterprise : technology : genius ------------------------------------------------------------------------------------------------------------------ Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695email:diego....@rbxglobal.com|www.rbxglobal.com------------------------------------------------------------------------------------------------------------------  signature.asc < 1KViewDownload> Director / System Operations

[walker333]

Hello,
recently I reported the same problem with disconnects every 5 seconds
when I use the "set nameserver" option. My setup was a macbook running
Leopard (all patches applied) and tunnelblick b16. Then I was given
b17 and everything worked perfectly. Please note that I'm getting two
(2) nameservers via DHCP from my ISP.
Then I upgraded to SL without any problem. Today I tried b18 and
encountered the same disconnecting problem, so I returned to b17. Also
I encountered another problem with b18, I saved my credentials in the
keychain and although I can see them stored, tunnelblick asks for them
again during a new connection.

Best regards,
Dimitris

On Sep 23, 6:33 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> A new release is out that includes the scripts as updated in r183.
>
> On Sep 22, 4:16 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
>
>
>
> > However, you have to take into account that using manual DNS's will, in general, take a dump on any DNS configuration you might later obtain from the OpenVPN server because of how DNS works.  The only way around this is to use Mac's "zoned DNS" approach where you can specify which DNS will be used to resolve which names.  This is a wholly manual approach, however, and it's also important to note that if this is going to be the case, then using "Set Nameserver" doesn't make a whole lot of sense anyway.
> > Cheers.

> > jkbull...gmail.com wrote:If you are talking about Diego's scripts of August 22, they were commited as r160 on August 25. They are not in a release yet; 3.0b16 was released on August 22. Note that the scripts were updated in r183 on September 8 to support WINS configuration gotten from the OpenVPN server. The r183 scripts will be in the next release, which I expect will be by the end of this month. On Sep 22, 7:44 am, Diego Rivera<diego.riv...@rbxglobal.com>wrote:This behavior has already been corrected.  Not sure when the release will be made.  Can somebody confirm if 3b14 or 3b16 (or which) release has the fix for this? Thanks! swa66 wrote:Glad to have found this. I had indeed added a fixed DNS server for the airport interface while on a trip (where the hotel's DHCP server didn't assign any DNS server for some reason). I fail to see the reason for persisting a behavior where the connection is built up and broken down and only a rather obscure message is logged. So I'd suggest to - log the problem clearly: "you have configured a fixed DNS server" - not build up and break down the connection in an endless loop (there's nothing useful in doing that) - override the DNS settings while the conection is up and restore them afterwards. I honestly fail to see why -for a VPN where the administrator attracts DNS resolution to a central server- there should be any importance at all to what the DNS server settings were prior to the connection being brought up, let alone how they were established. The purpose of the setign is to override local settings, no matter how they came to be or why they are. As it is now: - obscure error message at best, not even hinting at the real problem at all - endless loop of building and breaking the connection it's about the worst possible user experience. SWA On Aug 24, 5:56 am, Diego Rivera<diego.riv...@rbxglobal.com>wrote:Thinking about this a little more this only makes sense in cases where your manually-configured DNS would somehow become inaccessible once the OpenVPN link is up (i.e. is not in your local subnet, and you're using the OpenVPN link as your default gateway, and that DNS isn't accessible via that route, for instance - other scenarios are possible).  That way the configuration can stay, but the "fallback" (secondary, whatever you want to call them) nameservers are used (i.e. the ones that OpenVPN provided Tunnelblick) since the primary (or primaries, however the case may be) won't be accessible. Needless to say this will provide a somewhat lo usy user experience as any lookup will have to wait until the resolver times out while attempting to contact each of the DNS's in turn until it reaches the ones provided by OpenVPN which, presumably, would be accessible. Again - it will help tremendously if you try to explain exactly what you're trying to accomplish here so we can factor all that in.> Director / System Operations Roundbox Global :enterprise : technology : genius --------------------------------------------------------------------------- --------------------------------------- Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695email:diego.riv...@rbxglobal.com|www.rbxglobal.com----------------------------------------------------... signature.asc < 1KViewDownload> Director / System Operations

> > Roundbox Global :enterprise : technology : genius
> > --------------------------------------------------------------------------- ---------------------------------------
> > Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
> > tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695

> > email:diego.riv...@rbxglobal.com|www.rbxglobal.com
> > --------------------------------------------------------------------------- ---------------------------------------
>
> >  signature.asc
> > < 1KViewDownload

[Jérôme Le Gal]

Hello,

I encounter the same problem with Tunnelblick b18 : disconnections
every 5 sec when using it with "Utiliser DNS distant" (French
version). So I tried b16 and it works fine !

Server : OpenVPN 2.0.6 on FreeBSD,
Client : Tunnelblick b16 on Snow Leopard (MacBook Pro 13").

Tell me if you want any informations that can help you.

Best regards,
Jérôme

[jkbull...gmail.com]

Walker333 and Jerome: Please try the script that is attached to
Diego's 8/24 comment on this thread (his 3rd comment on this thread
altogether). Instructions for installing it are in the comment. Let us
know if that solves the disconnects every 5 seconds problem.

Walker333: I'm looking into the credentials issue.

[walker333]

Hello again,
I tried without any success. Same problem, disconnects every 5
seconds, exactly.
Dimitris

[Diego Rivera]

Do you have any manually-set TCP/IP configurations? DNS, anything?

walker333 wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

--

Diego Rivera

Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------

Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695

email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

[walker333]

I have manually configured IP only ("Using DHCP with manual address"
option).

Dimitris

On Sep 24, 8:00 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> Do you have any manually-set TCP/IP configurations? DNS, anything?

> walker333 wrote:Hello again, I tried without any success. Same problem, disconnects every 5 seconds, exactly. Dimitris On Sep 24, 6:59 pm, "jkbull...gmail.com"<jkbull...@gmail.com>wrote:Walker333 and Jerome: Please try the script that is attached to Diego's 8/24 comment on this thread (his 3rd comment on this thread altogether). Instructions for installing it are in the comment. Let us know if that solves the disconnects every 5 seconds problem. Walker333: I'm looking into the credentials issue. On Sep 24, 10:09 am, Jérôme Le Gal<jle...@simplerezo.com>wrote:Hello,I encounter the same problem with Tunnelblick b18 : disconnections every 5 sec when using it with "Utiliser DNS distant" (French version). So I tried b16 and it works fine !Server : OpenVPN 2.0.6 on FreeBSD, Client : Tunnelblick b16 on Snow Leopard (MacBook Pro 13").Tell me if you want any informations that can help you.Best regards, JérômeOn 23 sep, 20:00, walker333<D.Matsa...@noc.ntua.gr>wrote:Hello, recently I reported the same problem with disconnects every 5 seconds when I use the "set nameserver" option. My setup was a macbook running Leopard (all patches applied) and tunnelblick b16. Then I was given b17 and everything worked perfectly. Please note that I'm getting two (2) nameservers via DHCP from my ISP. Then I upgraded to SL without any problem. Today I tried b18 and encountered the same disconnecting problem, so I returned to b17. Also I encountered another problem with b18, I saved my credentials in the keychain and although I can see them stored, tunnelblick asks for them again during a new connection.Best regards, Dimitris> Director / System Operations

> Roundbox Global :enterprise : technology : genius
> ------------------------------------------------------------------------------------------------------------------
> Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
> email:diego....@rbxglobal.com|www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>

>  signature.asc
> < 1KViewDownload

[jkbull...gmail.com]

I have sent test builds privately to walker333 and Jerome Le Gal to
try to isolate the change from 3.0b16 to 3.0b18 that causes the
disconnects problem.

[raato]

Just to report in my experiences I had this exact same trouble
disconnecting every 5 seconds. I upgraded from 10.4.x Tiger to 10.6.1
Snow Leopard and decided to upgrade my Tunnelblick at the same time.

I tried b18, b16 and b14 and they all failed but b10 somehow works. As
far as I've understood I haven't set any DNS's manually on my
connection. My "set nameserver" option was on and as I said I'm using
snow leopard 10.6.1.

Nothing special in my client.conf - the exact same configuration has
worked (and works) on earlier Tunnelblick versions (atleast b9) on
Tiger and it works on Windows and Linux workstations as well.

[lenn]

Same problem here. Thought it was fixed a few weeks ago and now my MBP
disconnects after 5 secs. My iMacCoreDuo doesn't do this. Both are
running 10.6.1 and are on the same airport express wireless network.
Set nameserver is on and I don't set DNS manually.

lenn

[Diego Rivera]

This MUST be a change in how DNS information is stored and retrieved using scutil.  The current DNS management scripts are known to be correct for 10.4.x (Tiger) and 10.5.x (Leopard).  Luckily, I now have Snow Leopard so it should be a matter of days before we get this resolved (need to find the time window to do the upgrade such that I don't lose productivity for an entire day).

Cheers.

lenn wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

--

Diego Rivera

Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695

email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

[Diego Rivera]

Sure enough - this is a subtle, stupid change in Snow Leopard.  I need to figure out a simple way around this, else I'll have to write a full-blown scutil output parser (which not only do I not want to do, I think it's overkill for our purposses).

For now, consider the "Set Nameserver" option broken for Snow Leopard.  I'll start working on a fix - though this is somewhat complicated.

Cheers.

Diego Rivera wrote:

This MUST be a change in how DNS information is stored and retrieved using scutil.  The current DNS management scripts are known to be correct for 10.4.x (Tiger) and 10.5.x (Leopard).  Luckily, I now have Snow Leopard so it should be a matter of days before we get this resolved (need to find the time window to do the upgrade such that I don't lose productivity for an entire day).

Cheers.

lenn wrote:

Same problem here. Thought it was fixed a few weeks ago and now my MBP
disconnects after 5 secs. My iMacCoreDuo doesn't do this. Both are
running 10.6.1 and are on the same airport express wireless network.
Set nameserver is on  and I don't set DNS manually.

lenn

On Sep 26, 12:23 am, raato <ra...@mulletronic.com> wrote:
  

Just to report in my experiences I had this exact same trouble
disconnecting every 5 seconds. I upgraded from 10.4.x Tiger to 10.6.1
Snow Leopard and decided to upgrade my Tunnelblick at the same time.

I tried b18, b16 and b14 and they all failed but b10 somehow works. As
far as I've understood I haven't set any DNS's manually on my
connection. My "set nameserver" option was on and as I said I'm using
snow leopard 10.6.1.

Nothing special in my client.conf - the exact same configuration has
worked (and works) on earlier Tunnelblick versions (atleast b9) on
Tiger and it works on Windows and Linux workstations as well.
    

--

Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

[Diego Rivera]

Just for clarification, here is the output from the debug version of the leasewatch script I have in place:

Tue Sep 29 08:37:51 CST 2009: DNS configuration has changed:
--- BEGIN "GOOD" DNS CFG ---
<dictionary> {
  DomainName : cr.rbxglobal.com
  ServerAddresses : <array> {
    0 : 10.2.0.1
    1 : 10.1.0.1
  }
  SearchDomains : <array> {
    0 : cr.rbxglobal.com
  }
}
---- END "GOOD" DNS CFG ----
--- BEGIN CURRENT DNS CFG ---
<dictionary> {
  ServerAddresses : <array> {
    0 : 10.2.0.1
    1 : 10.1.0.1
  }
  DomainName : cr.rbxglobal.com
  SearchDomains : <array> {
    0 : cr.rbxglobal.com
  }
}
---- END CURRENT DNS CFG ----

Tue Sep 29 08:38:14 CST 2009: WINS configuration has changed:
--- BEGIN "GOOD" WINS CFG ---
<dictionary> {
  Workgroup : CRRBXGLOBAL
  WINSAddresses : <array> {
    0 : 10.2.0.32
    1 : 10.1.0.10
  }
}
---- END "GOOD" WINS CFG ----
--- BEGIN CURRENT WINS CFG ---
<dictionary> {
  WINSAddresses : <array> {
    0 : 10.2.0.32
    1 : 10.1.0.10
  }
  Workgroup : CRRBXGLOBAL
}
---- END CURRENT WINS CFG ----

If either WINS or DNS configurations mismatch, leasewatch instructs tunnelblick to renegotiate the link to correct any DNS configurations, because it presumes that DHCP is at play and has re-set the DNS configurations overriding those set by OpenVPN (which is obviously not what we want if we're using "Set Nameserver").  It does so very simply: it lists the output from the currently active system configruation (for either DNS or WINS), and compares it to the output of a previously generated copy of that configuration.  The copies are generated separately following the exact same algorithm, and taking care of properly aggregating DNS configurations just like the O/S does.

Thus, the assumption (now, apparently wrong!) is that the output of A will match the output of B if A==B.  However, if you look at the above, the output is slightly different: the position of the "Workgroup:" and "DomainName:" entries has changed within the output.  Thus, while A==B, output(A) != output(B).  Thus, our script can no longer take the shortcut it used (comparing outputs) to determine if the contents are the same.

This was a design choice to avoid the complexities of having to manually parse and analyze the output for comparison (a lot more work, a lot more complex).

Thank you, Apple, for yet again unilaterally violating our anal cavities with nonsensical changes that have no other effect but to break things that didn't need breaking or fixing.

I'll get back to you guys when I have something to report on this end.

Cheers!


Diego Rivera wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

[jkbull...gmail.com]

A fix for this problem has been submitted as r198. Refer to the
instructions in my recent comment in Issue 113 to download and install
a patch.

Issue 113 may be found at
http://code.google.com/p/tunnelblick/issues/detail?id=113#c5

[lenn]

Just installed the 3 files. Restarted TB. Still getting the disconnect
after 5 seconds.

[Diego Rivera]

Please attach (in zipped form or some other compressed form) the contents of the file /tmp/Tunnelblick-Leasewatch.log so we can take a look and determine why the script failed to do its job.

Thanks!

lenn wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

[Diego Rivera]

Ok I've taken the time to research this further.  It appears that Apple has finally come to their senses regarding DHCP-aggregation of DNS and Search Domain settings (albeit breaking half a billion things in the process).  Turns out that the MacOS X TCP/IP stack will no longer aggregate manually-added DNS or Search Domain (or WINS, for that matter) entries to those added by DHCP - at least not in the way Leopard/Tiger do.  This is the sensible way to manage these configurations - of course, nothing (as far as I know) was announced about it and hence our scripts paid the price for it.

Things being what they are, it really makes no sense to use "Set Nameserver" when you're using manual DNS entries (Search Domains or DNS) since the O/S will not aggregate them and continue to use only the manually-set configurations.  I will modify the scripts accordingly to ignore each of the OpenVPN-provided settings for DNS, WINS and Search Domains when there are static values for each of those set (i.e. if static DNS is set, ignore DNS, if static WINS is set ignore WINS, etc...each independent of the others).

I need to test them in Leopard before I let them loose upon the world (I have no reason to think they won't work, but still - better safe than sorry).

We could alter the scripts to perform the aggregation anyway and *FORCE* the issue, but this wouldn't be correct and I'm not sure what parts of MacOS would break because of it.  Furthermore, this would break the functionality from LeaseWatch that permits the detection of link parameter changes (i.e. change of client IP, change of network, etc).  All in all, forcing this is a *BAD IDEA*.  So don't ask. :)

So for now, Snow Leopard *will not* support aggregation of static DNS/WINS/Search Domains with OpenVPN-obtained ones.  If you want to use static settings, you're basically ordering the O/S to ignore the dynamic ones you would obtain from Tunnelblick.  This is how things work in the sensible universe for every other operating system out there.  So deal with it :)

Will update you when I have the updated scripts ready for testing.

Cheers.

[Diego Rivera]

Thinking it through some more, the only way this would be feasible is
if it were possible to tell the OS that such aggregation is desired
or, failing that, telling it *which* configurations are to be used as
active (i.e. when the VPN is up use only the settings from the VPN).

I'm afraid I don't have enough information on the O/S to figure that
one out, but if anyone has any pointers to offer I'll be happy to look
into it. Importantly, this has to be a natural mechanism through
which we would NOT be forcing the active configuration to take one
shape or another. What we would do is configure the OpenVPN
connection established by Tunnelblick and then tell the O/S that it
should use the settings for that connection as the primary ones for
the whole system. That's where the trick is... I don't know how to do
that or even if it's doable.

Cheers.

[jkbull...gmail.com]

Tunnelblick 3.0b20 has been released and is available on the downloads
page:
http://code.google.com/p/tunnelblick/downloads/list

Release Notes are available at:
http://code.google.com/p/tunnelblick/wiki/ReleaseNotes

It includes fixes for problems using "Set nameserver" on Snow Leopard.

[lenn]

Just installed b20. Unfortunately is doesn't fix my disconnect after 5
sec problem :( Back to b10.
lenn

[jkbull...gmail.com]

lenn - Please reply and attach (in zipped form or some other

compressed form) the contents of the file /tmp/Tunnelblick-

Leasewatch.log so we can see what's happening. Thanks.

[Diego Rivera]

What version of Mac OS X are you using?  The fixes are confirmed for Tiger, Leopard, and Snow Leopard...

Also, please post a description of any manually-set TCP/IP settings (DNS, search domains, WINS, whatever is manually configured).

Cheers.

lenn wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

  

[Diego Rivera]

And yes - as Jonathan said - please post the (zipped) contents of /tmp/Tunnelblick-Leasewatch.log so we can help figure out the problem.

Cheers.

[Jérôme Le Gal]

It's worse :(

I have this message "event_wait : Interrupted system call (code=4)", when using "set nameserver" or not... And not after 5 sec, but directly.

I don't have the log file in /tmp. So sorry, i don't know how to help you now.

Jérôme

MacBook on Snow Leopard

Support Technique	SimpleRezo
Jérôme	www.simplerezo.com

 

[Diego Rivera]

Are you running 32-bit or 64-bit snow leopard?

Jérôme Le Gal wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jérôme Le Gal]

  Apparently i'm using a 32bits version :

Noyau et extensions 64 bits : Non

--

Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

[Jérôme Le Gal]

Sorry, it works fine. I was using a wrong certificate... Shame on me !

Jerome

[Wes Plate]

I had this happen to me for the first time with one of my users who was
using Tunnelblick for the first time. I had him go back to build 16 and
that seemed to correct it for him.

What information can I send you to help?

--
Wes Plate
Automatic Duck, Inc.
http://www.automaticduck.com

[jkbull...gmail.com]

Please post the OS X version and the Tunnelblick version and build,
and details of his network setup (DHCP, manual, etc.)

If he is running Tunnelblick 3.0b20, attach the contents of the file /
tmp/Tunnelblick-Leasewatch.log (compressed, if possible).

[Diego Rivera]

b20 should work on all versions of MacOS X except in 64-bit node (this is a known issue with OpenVPN).  Can you have him try with b20 and send us the contents of /tmp/Tunnelblick-Leasewatch.log?

Cheers.

Wes Plate wrote:

I had this happen to me for the first time with one of my users who was
using Tunnelblick for the first time.  I had him go back to build 16 and
that seemed to correct it for him.

What information can I send you to help?


  

--

[Wes Plate]

On 10/14/09 6:27 AM, "Diego Rivera" <diego....@rbxglobal.com> wrote:

> b20 should work on all versions of MacOS X except in 64-bit node (this is a
> known issue with OpenVPN). Can you have him try with b20 and send us the
> contents of /tmp/Tunnelblick-Leasewatch.log?

b20 was the version we tried first.

I'm requesting the file for you.

[Wes Plate]

On 10/13/09 11:29 PM, "jkbull...gmail.com" <jkbu...@gmail.com> wrote:

> Please post the OS X version and the Tunnelblick version and build,
> and details of his network setup (DHCP, manual, etc.)
>
> If he is running Tunnelblick 3.0b20, attach the contents of the file /
> tmp/Tunnelblick-Leasewatch.log (compressed, if possible).

OS 10.5.4

DHCP

Log from b20 follows...

2009-10-14 13:08:12 *Tunnelblick: Tunnelblick 3 (3.0b20 build 1206);
OpenVPN 2 (2.1_rc19)
2009-10-14 13:08:15 SUCCESS: pid=7659
2009-10-14 13:08:15 SUCCESS: real-time state notification set to ON
2009-10-14 13:08:15 SUCCESS: real-time log notification set to ON
2009-10-14 13:08:15 OpenVPN 2.1_rc19 i386-apple-darwin9.8.0 [SSL]
[LZO2] [PKCS11] built on Oct 9 2009
2009-10-14 13:08:15 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2009-10-14 13:08:15 waiting...
2009-10-14 13:08:15 MANAGEMENT: Client connected from 127.0.0.1:1337
2009-10-14 13:08:15 MANAGEMENT: CMD 'pid'
2009-10-14 13:08:15 MANAGEMENT: CMD 'state on'
2009-10-14 13:08:15 MANAGEMENT: CMD 'log on all'
2009-10-14 13:08:15 END
2009-10-14 13:08:15 MANAGEMENT: CMD 'hold release'
2009-10-14 13:08:15 SUCCESS: hold release succeeded
2009-10-14 13:08:15 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2009-10-14 13:08:15 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2009-10-14 13:08:15 WARNING: file 'client.key' is group or others
accessible
2009-10-14 13:08:15 LZO compression initialized
2009-10-14 13:08:15 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2009-10-14 13:08:15 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2009-10-14 13:08:15 Local Options hash (VER=V4): 'd79ca330'
2009-10-14 13:08:15 Expected Remote Options hash (VER=V4): 'f7df56b8'
2009-10-14 13:08:15 Socket Buffers: R=[42080->65536] S=[9216->65536]
2009-10-14 13:08:15 UDPv4 link local: [undef]
2009-10-14 13:08:15 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:15
2009-10-14 13:08:15
2009-10-14 13:08:15 sid=019d002e 0f39df4c
2009-10-14 13:08:15
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:15
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:16 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:16 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:16 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:16 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:16 1024 bit RSA
2009-10-14 13:08:16 [someName] Peer Connection Initiated with
XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:17
2009-10-14 13:08:17 SENT CONTROL [someName]: 'PUSH_REQUEST' (status=1)
2009-10-14 13:08:17 ifconfig 10.38.25.155 255.255.255.0'
2009-10-14 13:08:17 OPTIONS IMPORT: timers and/or timeouts modified
2009-10-14 13:08:17 OPTIONS IMPORT: --ifconfig/up options modified
2009-10-14 13:08:17 OPTIONS IMPORT: route options modified
2009-10-14 13:08:17 OPTIONS IMPORT: route-related options modified
2009-10-14 13:08:17 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2009-10-14 13:08:17 ROUTE default_gateway=192.168.103.233
2009-10-14 13:08:17 TUN/TAP device /dev/tap0 opened
2009-10-14 13:08:17
2009-10-14 13:08:17 /sbin/ifconfig tap0 delete
2009-10-14 13:08:17 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2009-10-14 13:08:17 /sbin/ifconfig tap0 10.38.25.155 netmask
255.255.255.0 mtu 1500 up
2009-10-14 13:08:17 /Applications/Tunnelblick.app/Contents/Resources/
client.up.osx.sh tap0 1500 1574 10.38.25.155 255.255.255.0 init
2009-10-14 13:08:17
2009-10-14 13:08:17 /sbin/route add -net 10.38.25.0 10.38.25.85
255.255.255.0
2009-10-14 13:08:17 Initialization Sequence Completed
2009-10-14 13:08:17 XXX.XXX.XXX.XXX
2009-10-14 13:08:22 event_wait : Interrupted system call (code=4)
2009-10-14 13:08:22 TCP/UDP: Closing socket
2009-10-14 13:08:22 /Applications/Tunnelblick.app/Contents/Resources/
client.down.osx.sh tap0 1500 1574 10.38.25.155 255.255.255.0 restart
2009-10-14 13:08:22 process restarting
2009-10-14 13:08:22
2009-10-14 13:08:22 MANAGEMENT: CMD 'hold release'
2009-10-14 13:08:22 SUCCESS: hold release succeeded
2009-10-14 13:08:22 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2009-10-14 13:08:22 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2009-10-14 13:08:22 Re-using SSL/TLS context
2009-10-14 13:08:22 LZO compression initialized
2009-10-14 13:08:22 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2009-10-14 13:08:22 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2009-10-14 13:08:22 Local Options hash (VER=V4): 'd79ca330'
2009-10-14 13:08:22 Expected Remote Options hash (VER=V4): 'f7df56b8'
2009-10-14 13:08:22 Socket Buffers: R=[42080->65536] S=[9216->65536]
2009-10-14 13:08:22 UDPv4 link local: [undef]
2009-10-14 13:08:22 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:22
2009-10-14 13:08:22
2009-10-14 13:08:22 sid=a4a101a3 6b63e3ee
2009-10-14 13:08:22
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:22
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:23 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:23 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:23 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:23 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:23 1024 bit RSA
2009-10-14 13:08:23 [someName] Peer Connection Initiated with
XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:24
2009-10-14 13:08:24 SENT CONTROL [someName]: 'PUSH_REQUEST' (status=1)
2009-10-14 13:08:24 ifconfig 10.38.25.155 255.255.255.0'
2009-10-14 13:08:24 OPTIONS IMPORT: timers and/or timeouts modified
2009-10-14 13:08:24 OPTIONS IMPORT: --ifconfig/up options modified
2009-10-14 13:08:24 OPTIONS IMPORT: route options modified
2009-10-14 13:08:24 OPTIONS IMPORT: route-related options modified
2009-10-14 13:08:24 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2009-10-14 13:08:24 Preserving previous TUN/TAP instance: tap0
2009-10-14 13:08:24 /Applications/Tunnelblick.app/Contents/Resources/
client.up.osx.sh tap0 1500 1574 10.38.25.155 255.255.255.0 restart
2009-10-14 13:08:24 Initialization Sequence Completed
2009-10-14 13:08:24 XXX.XXX.XXX.XXX
2009-10-14 13:08:29 event_wait : Interrupted system call (code=4)
2009-10-14 13:08:29 TCP/UDP: Closing socket
2009-10-14 13:08:29 /Applications/Tunnelblick.app/Contents/Resources/
client.down.osx.sh tap0 1500 1574 10.38.25.155 255.255.255.0 restart
2009-10-14 13:08:29 process restarting
2009-10-14 13:08:29
2009-10-14 13:08:29 MANAGEMENT: CMD 'hold release'
2009-10-14 13:08:29 SUCCESS: hold release succeeded
2009-10-14 13:08:29 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2009-10-14 13:08:29 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2009-10-14 13:08:29 Re-using SSL/TLS context
2009-10-14 13:08:29 LZO compression initialized
2009-10-14 13:08:29 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2009-10-14 13:08:29 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2009-10-14 13:08:29 Local Options hash (VER=V4): 'd79ca330'
2009-10-14 13:08:29 Expected Remote Options hash (VER=V4): 'f7df56b8'
2009-10-14 13:08:29 Socket Buffers: R=[42080->65536] S=[9216->65536]
2009-10-14 13:08:29 UDPv4 link local: [undef]
2009-10-14 13:08:29 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:29
2009-10-14 13:08:29
2009-10-14 13:08:29 sid=b4930b37 2dc982b2
2009-10-14 13:08:29
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:29
/C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=na...@domain.com
2009-10-14 13:08:30 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:30 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:30 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2009-10-14 13:08:30 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2009-10-14 13:08:30 1024 bit RSA
2009-10-14 13:08:30 [someName] Peer Connection Initiated with
XXX.XXX.XXX.XXX:1194
2009-10-14 13:08:31
2009-10-14 13:08:31 SENT CONTROL [someName]: 'PUSH_REQUEST' (status=1)
2009-10-14 13:08:31 ifconfig 10.38.25.155 255.255.255.0'
2009-10-14 13:08:31 OPTIONS IMPORT: timers and/or timeouts modified
2009-10-14 13:08:31 OPTIONS IMPORT: --ifconfig/up options modified
2009-10-14 13:08:31 OPTIONS IMPORT: route options modified
2009-10-14 13:08:31 OPTIONS IMPORT: route-related options modified
2009-10-14 13:08:31 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2009-10-14 13:08:31 Preserving previous TUN/TAP instance: tap0
2009-10-14 13:08:31 /Applications/Tunnelblick.app/Contents/Resources/
client.up.osx.sh tap0 1500 1574 10.38.25.155 255.255.255.0 restart
2009-10-14 13:08:31 Initialization Sequence Completed
2009-10-14 13:08:31 XXX.XXX.XXX.XXX

[jkbull...gmail.com]

Thanks. That's the OpenVPN log. What we need is the Tunnelblick log,
at
/tmp/Tunnelblick-Leasewatch.log

On Oct 14, 5:31 pm, Wes Plate <w...@automaticduck.com> wrote:

> has been enabled.  Seehttp://openvpn.net/howto.html#mitmfor more info.

> 2009-10-14 13:08:15 NOTE: the current --script-security setting may
> allow this configuration to call user-defined scripts
> 2009-10-14 13:08:15 WARNING: file 'client.key' is group or others
> accessible
> 2009-10-14 13:08:15 LZO compression initialized
> 2009-10-14 13:08:15 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
> 0 ET:0 EL:0 ]
> 2009-10-14 13:08:15 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
> 135 ET:32 EL:0 AF:3/1 ]
> 2009-10-14 13:08:15 Local Options hash (VER=V4): 'd79ca330'
> 2009-10-14 13:08:15 Expected Remote Options hash (VER=V4): 'f7df56b8'
> 2009-10-14 13:08:15 Socket Buffers: R=[42080->65536] S=[9216->65536]
> 2009-10-14 13:08:15 UDPv4 link local: [undef]
> 2009-10-14 13:08:15 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
> 2009-10-14 13:08:15
> 2009-10-14 13:08:15
> 2009-10-14 13:08:15  sid=019d002e 0f39df4c
> 2009-10-14 13:08:15

> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com
> 2009-10-14 13:08:15
> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com

> has been enabled.  Seehttp://openvpn.net/howto.html#mitmfor more info.

> 2009-10-14 13:08:22 NOTE: the current --script-security setting may
> allow this configuration to call user-defined scripts
> 2009-10-14 13:08:22 Re-using SSL/TLS context
> 2009-10-14 13:08:22 LZO compression initialized
> 2009-10-14 13:08:22 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
> 0 ET:0 EL:0 ]
> 2009-10-14 13:08:22 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
> 135 ET:32 EL:0 AF:3/1 ]
> 2009-10-14 13:08:22 Local Options hash (VER=V4): 'd79ca330'
> 2009-10-14 13:08:22 Expected Remote Options hash (VER=V4): 'f7df56b8'
> 2009-10-14 13:08:22 Socket Buffers: R=[42080->65536] S=[9216->65536]
> 2009-10-14 13:08:22 UDPv4 link local: [undef]
> 2009-10-14 13:08:22 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
> 2009-10-14 13:08:22
> 2009-10-14 13:08:22
> 2009-10-14 13:08:22  sid=a4a101a3 6b63e3ee
> 2009-10-14 13:08:22

> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com
> 2009-10-14 13:08:22
> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com

> has been enabled.  Seehttp://openvpn.net/howto.html#mitmfor more info.

> 2009-10-14 13:08:29 NOTE: the current --script-security setting may
> allow this configuration to call user-defined scripts
> 2009-10-14 13:08:29 Re-using SSL/TLS context
> 2009-10-14 13:08:29 LZO compression initialized
> 2009-10-14 13:08:29 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
> 0 ET:0 EL:0 ]
> 2009-10-14 13:08:29 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
> 135 ET:32 EL:0 AF:3/1 ]
> 2009-10-14 13:08:29 Local Options hash (VER=V4): 'd79ca330'
> 2009-10-14 13:08:29 Expected Remote Options hash (VER=V4): 'f7df56b8'
> 2009-10-14 13:08:29 Socket Buffers: R=[42080->65536] S=[9216->65536]
> 2009-10-14 13:08:29 UDPv4 link local: [undef]
> 2009-10-14 13:08:29 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
> 2009-10-14 13:08:29
> 2009-10-14 13:08:29
> 2009-10-14 13:08:29  sid=b4930b37 2dc982b2
> 2009-10-14 13:08:29

> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com
> 2009-10-14 13:08:29
> /C=US/ST=WA/L=OurTown/O=OurCompany/CN=someName/emailAddress=n...@domain.com

[bill powell]

It might be a problem with my Macbook. When I try to drag the Tunnelblick.dmg to the apps file I get the following message: "The operation cannot be completed because you do not have sufficient privileges for some of the items." I have no idea what that means.

bill

[walker333]

Hello Bill,
move your old tunnelblick application from the Applications folder to
the trash before trying to copy the new one from the dmg to your
Applications folder.
Dimitris

On Oct 15, 10:56 am, bill powell <billasia2...@gmail.com> wrote:
> It might be a problem with my Macbook. When I try to drag the
> Tunnelblick.dmg to the apps file I get the following message: "The operation
> cannot be completed because you do not have sufficient privileges for some
> of the items." I have no idea what that means.bill
>

> > > has been enabled.  Seehttp://openvpn.net/howto.html#mitmformore info.

> > > has been enabled.  Seehttp://openvpn.net/howto.html#mitmformore info.

> > > has been enabled.  Seehttp://openvpn.net/howto.html#mitmformore info.

> ...
>
> read more »

[sbolay]

Dear all,

This is a small case report based on this last night.
OSX 10.6.1

Tunnelblick 3 (3.0b20 build 1206)

And I had the same problem has everybody here:

event_wait : Interrupted system call (code=4)

TCP/UDP: Closing socket
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh
tun0 1500 1542 172.27.17.14 172.27.17.13 restart
SIGUSR1[hard,] received, process restarting

So I did some checks:

$ launchctl list | grep tunnel
20725 - [0x0-0x81081].com.openvpn.tunnelblick


$ cat /tmp/Tunnelblick-Leasewatch.log
Thu Oct 29 15:59:54 CET 2009: DNS configuration has changed:

--- BEGIN "GOOD" DNS CFG ---
<dictionary> {

SearchDomains : <array> {
0 : irovision.ch
}
ServerAddresses : <array> {
0 : 192.168.10.122
1 : 192.168.10.123
}
DomainName : irovision.ch

}
---- END "GOOD" DNS CFG ----
--- BEGIN CURRENT DNS CFG ---
<dictionary> {
ServerAddresses : <array> {

0 : 192.168.10.122
1 : 192.168.10.123
}
DomainName : irovision.ch

}
---- END CURRENT DNS CFG ----

Thu Oct 29 15:59:54 CET 2009: WINS configuration has changed:

--- BEGIN "GOOD" WINS CFG ---
<dictionary> {

Workgroup : <array> {
0 : No
1 : such
2 : key
}
WINSAddresses : <array> {
0 : 192.168.10.80

}
}
---- END "GOOD" WINS CFG ----
--- BEGIN CURRENT WINS CFG ---
<dictionary> {
WINSAddresses : <array> {

0 : 192.168.10.80

}
}
---- END CURRENT WINS CFG ----

Thu Oct 29 15:59:54 CET 2009: Sending USR1 to OpenVPN PID 26629


$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain irovision.ch
nameserver 192.168.10.122
nameserver 192.168.10.123


sbolay@sbolay:/System/Library/LaunchAgents$ scutil --dns
DNS configuration

resolver #1
domain : irovision.ch
search domain[0] : irovision.ch
nameserver[0] : 192.168.10.122
nameserver[1] : 192.168.10.123
order : 200000


So I was looking for a good reason why /etc/resolv.conf does not
contains the SEARCH keyword.

The first thing I found is that this file was hard codded instead of
being a symlink to /var/run/resolv.conf
So I did a:
/etc/$ ln -s /var/run/resolv.conf

But this doesn't change anything but to have both file identical ;-)

Then I tried to understand why the SEARCH keyword is not pushed into
the resolv.conf and I tried various solutions.
One of them did the trick:
In the "Network Preferences" I manually add my domain in the "Search
Domains" field.
Then I did a connection and then disconnected again.
Finally removed the just added domain in the "Search Domains" field
and did a connection. This time, I was really surprised to see in the
resolv.conf:

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain irovision.ch
search irovision.ch
nameserver 192.168.10.122
nameserver 192.168.10.123

And since that, Tunnelblick runs well!!!

I tried this only small stuff on another OSX10.6.1 and manually adding
removing the "Search Domains" was sufficient to make Tunnelblick
working!

What we can also see from here is that behavior probably occurred
because I'm trying to establish a connection where both my LAN DNS
server and the OpenVPN server serve the same dns informations.

I think that would not occur while doing a connection if OpenVPN dns
informations are different from the LAN.

Finally, the last hint is that I think that if the script
"client.up.osx.sh" does not set the "d.add SearchDomains * $
{SEARCH_DOMAIN}" option with scutil, this will probably never occur,
because both "GOOD" DNS CFG and the CURRENT DNS CFG would be the
same. ALSO, if I prefer to have it in my resolv.conf!!!

I hope this case report may help developer to find the way for a fix!
Good Luck and Thank you for all your work!

Best,
Sylvain Bolay
http://wiki.bolay.net

[Alexei Gretchaninov]

Hello everyone,

The same issue appeared again with b22 right after I've installed
recent AirPort update for Snow Leopard.
Is there any solution yet?

[jkbull...gmail.com]

A fix for this was committed to the source code as r276 on 11/15/2009.
We hope to create a new release of Tunnelblick which incorporates it
soon.

[Alexei Gretchaninov]

Thank you! I will wait for new build.
Please announce it here so I will be notified.

[jkbull...gmail.com]

Tunnelblick version 3.0b24 has been released. It contains (among many
other changes) a fix for this issue.