option to not monitor WINS changes

[Michael Demmer]

When the VPN server on my company's network pushes a WINS
configuration change, this causes Tunnelblick to eventually fail the
connection. Below is the (sanitized) log snippet.

To fix this problem, I make the following change to the leasewatch script:

--- leasewatch 2011-04-05 12:58:08.000000000 -0700
+++ leasewatch- 2011-04-05 13:04:02.000000000 -0700
@@ -133,8 +133,7 @@
fi
fi

- # if [ "${WINS_GOOD}" != "${WINS_NOW}" ] ; then
- if [ 0 == 1 ] ; then
+ if [ "${WINS_GOOD}" != "${WINS_NOW}" ] ; then
if ${NOTHING_DISPLAYED} ; then
NOTHING_DISPLAYED="false"
echo "$(date '+%a %b %e %T %Y') *Tunnelblick leasewatch:
A network configuration change was detected" >> "${SCRIPT_LOG_FILE}"

Essentially this tells it to ignore all WINS configuration changes so
the connection stays up.

It would be great if either the underlying problem were fixable or if
the logic to monitor connections would allow me to select whether I
want to monitor for DNS or WINS or both, since in my case I need the
DNS updates but obviously don't want the WINS ones.

-m

---

2011-04-05 12:57:41 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-04-05 12:57:41 *Tunnelblick: Flushed the DNS cache
2011-04-05 12:57:46 *Tunnelblick leasewatch: A network configuration
change was detected
* WINS configuration has changed:
* --- BEGIN EXPECTED WINS CFG ---
* <dictionary> {
* WINSAddresses : <array> {
* 0 : 1.2.0.30
* }
* Workgroup : FOOTECH
* }
* ---- END EXPECTED WINS CFG ----
*
* --- BEGIN CURRENT WINS CFG ---
* <dictionary> {
* NetBIOSName : mdemmer-mac
* WINSAddresses : <array> {
* 0 : 1.2.0.30
* }
* Workgroup : FOOTECH
* }
* ---- END CURRENT WINS CFG ----
*
* --- BEGIN PRE-VPN WINS CFG ---
* <dictionary> {
* TunnelblickNoSuchKey : true
* }
* ---- END PRE-VPN WINS CFG ----
* Sending USR1 to OpenVPN
(process ID 4173) to restart the connection.
2011-04-05 12:57:47 us=605284 event_wait : Interrupted system call (code=4)
2011-04-05 12:57:47 us=608907 TCP/UDP: Closing socket
2011-04-05 12:57:47 us=916884 PLUGIN_CALL: POST
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so/PLUGIN_DOWN
status=0
2011-04-05 12:57:47 us=916951 SIGUSR1[hard,] received, process restarting
2011-04-05 12:57:47 us=916969 MANAGEMENT:
>STATE:1302033467,RECONNECTING,SIGUSR1,,
2011-04-05 12:57:47 us=920145 MANAGEMENT: CMD 'hold release'
2011-04-05 12:57:47 us=920496 NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
2011-04-05 12:57:47 us=920526 Re-using SSL/TLS context
2011-04-05 12:57:47 us=920543 LZO compression initialized
2011-04-05 12:57:47 us=920614 Control Channel MTU parms [ L:1542 D:166
EF:66 EB:0 ET:0 EL:0 ]
2011-04-05 12:57:47 us=920659 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-04-05 12:57:47 us=920731 Data Channel MTU parms [ L:1542 D:1450
EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
2011-04-05 12:57:47 us=931950 Local Options String: 'V4,dev-type
tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher
BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
2011-04-05 12:57:47 us=931972 Expected Remote Options String:
'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto
UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize
128,tls-auth,key-method 2,tls-server'
2011-04-05 12:57:47 us=931991 Local Options hash (VER=V4): '504e774e'
2011-04-05 12:57:47 us=932009 Expected Remote Options hash (VER=V4): '14168603'
2011-04-05 12:57:47 us=934602 UDPv4 link local: [undef]
2011-04-05 12:57:47 us=934639 UDPv4 link remote: 111.222.196.28:1194
2011-04-05 12:57:47 us=934679 MANAGEMENT: >STATE:1302033467,WAIT,,,
2011-04-05 12:57:47 us=940054 MANAGEMENT: >STATE:1302033467,AUTH,,,
2011-04-05 12:57:47 us=940384 TLS: Initial packet from
111.222.196.28:1194, sid=d05712f3 1ed5980a
2011-04-05 12:57:47 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-04-05 12:57:47 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations
2011-04-05 12:57:48 us=162682 VERIFY OK: depth=1,
/C=US/ST=CA/L=SF/O=Foo_Technologies__Inc./CN=OpenVPN-CA/emailAddress=ad...@footech.com
2011-04-05 12:57:48 us=166373 VERIFY OK: nsCertType=SERVER
2011-04-05 12:57:48 us=168823 VERIFY OK: depth=0,
/C=US/ST=CA/O=Foo_Technologies__Inc./CN=server/emailAddress=ad...@footech.com
2011-04-05 12:57:48 us=320173 Data Channel Encrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2011-04-05 12:57:48 us=320214 Data Channel Encrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2011-04-05 12:57:48 us=320471 Data Channel Decrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2011-04-05 12:57:48 us=320489 Data Channel Decrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2011-04-05 12:57:48 us=320548 Control Channel: TLSv1, cipher
TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
2011-04-05 12:57:48 us=320577 [server] Peer Connection Initiated with
111.222.196.28:1194
2011-04-05 12:57:49 us=411035 MANAGEMENT: >STATE:1302033469,GET_CONFIG,,,
2011-04-05 12:57:50 us=501731 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-04-05 12:57:50 us=507675 PUSH: Received control message:
'PUSH_REPLY,route 1.0.0.0 255.0.0.0,route 1.2.0.50
255.255.255.255,route 1.0.0.2 255.255.255.255,route 1.2.0.30
255.255.255.255,route 1.2.0.31 255.255.255.255,route 1.2.0.38
255.255.255.255,route 1.2.0.0 255.255.0.0,dhcp-option DNS
1.2.0.31,dhcp-option DNS 1.2.0.30,dhcp-option WINS
1.2.0.30,dhcp-option DOMAIN nbttech.com,route 1.3.128.0
255.255.192.0,topology net30,ping 10,ping-restart 120,ifconfig
1.3.132.30 1.3.132.29'
2011-04-05 12:57:50 us=507927 OPTIONS IMPORT: timers and/or timeouts modified
2011-04-05 12:57:50 us=507948 OPTIONS IMPORT: --ifconfig/up options modified
2011-04-05 12:57:50 us=507964 OPTIONS IMPORT: route options modified
2011-04-05 12:57:50 us=507979 OPTIONS IMPORT: --ip-win32 and/or
--dhcp-option options modified
2011-04-05 12:57:50 us=507995 Preserving previous TUN/TAP instance: tun0
2011-04-05 12:57:50 us=508060 PLUGIN_CALL: POST
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so/PLUGIN_UP
status=1
2011-04-05 12:57:50 us=508078 PLUGIN_CALL: plugin function PLUGIN_UP
failed with status 1:
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so
2011-04-05 12:57:50 us=508148 MANAGEMENT: Client disconnected
2011-04-05 12:57:50 us=508164 ERROR: up/down plugin call failed
2011-04-05 12:57:50 us=508180 Exiting
2011-04-05 12:57:50 us=508212 /sbin/route delete -net 1.3.128.0
1.3.132.29 255.255.192.0
delete net 1.3.128.0: gateway 1.3.132.29
2011-04-05 12:57:50 us=512751 /sbin/route delete -net 1.2.0.0
1.3.132.29 255.255.0.0
delete net 1.2.0.0: gateway 1.3.132.29
2011-04-05 12:57:50 us=517648 /sbin/route delete -net 1.2.0.38
1.3.132.29 255.255.255.255
delete net 1.2.0.38: gateway 1.3.132.29
2011-04-05 12:57:50 us=520226 /sbin/route delete -net 1.2.0.31
1.3.132.29 255.255.255.255
delete net 1.2.0.31: gateway 1.3.132.29
2011-04-05 12:57:50 us=523595 /sbin/route delete -net 1.2.0.30
1.3.132.29 255.255.255.255
delete net 1.2.0.30: gateway 1.3.132.29
2011-04-05 12:57:50 us=526293 /sbin/route delete -net 1.0.0.2
1.3.132.29 255.255.255.255
delete net 1.0.0.2: gateway 1.3.132.29
2011-04-05 12:57:50 us=529293 /sbin/route delete -net 1.2.0.50
1.3.132.29 255.255.255.255
delete net 1.2.0.50: gateway 1.3.132.29
2011-04-05 12:57:50 us=532283 /sbin/route delete -net 1.0.0.0
1.3.132.29 255.0.0.0
delete net 1.0.0.0: gateway 1.3.132.29
2011-04-05 12:57:50 us=534572 Closing TUN/TAP interface
launchctl: Couldn't stat(""):
No such file or directory
nothing found to unload
2011-04-05 12:57:50 us=634969 PLUGIN_CALL: POST
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so/PLUGIN_DOWN
status=1
2011-04-05 12:57:50 us=635010 PLUGIN_CALL: plugin function PLUGIN_DOWN
failed with status 1:
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so
2011-04-05 12:57:50 us=635037 ERROR: up/down plugin call failed
2011-04-05 12:57:50 us=635069 Exiting

[jkbull...gmail.com]

Thanks for your report. Making the WINS-change restarts optional is a good idea.

However, the restarts shouldn't fail. It looks like the up script is failing during the restart:

2011-04-05 12:57:50 us=508060 PLUGIN_CALL: POST /Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so/PLUGIN_UP status=1
2011-04-05 12:57:50 us=508078 PLUGIN_CALL: plugin function PLUGIN_UP failed with status 1: /Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so

Are there any messages in the system logs at this time that could shed any light on why/how the up script failed?

Could you try this, not using the openvpn-downroot.so plugin? That might help to isolate the problem. You will need to remove the "XXX-useDownRootPlugin" preference, where XXX is the name of the configuration and remove "user nobody" and "group nobody" from the configuration file. (When you restore the configuration file afterwards, a popup window will recreate the preference if you so indicate.)

[Michael Demmer]

I've had issues with Tunnelblick failing to restart for a long time
now and posted an earlier message to the list but couldn't come to a
resolution on it.

The only relevant thing I see in the logs is:
Apr 6 10:02:09 mdemmer-mac kernel[0]: Kext foo.tun not found for
unload request.

Also, I don't quite understand what you mean about removing the
XXX-useDownRootPlugin preference. I don't have the "user nobody /
group nobody" in the config file any more after a previous suggestion
to get rid of them, but it still seems to be trying to use the plugin.

Thanks,
-m

> --
> 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]

I'm sorry your problem wasn't resolved earlier; sometimes I lose track.

The plugin is used if the preference is set (even if there are no user/group options in the configuration file).

To remove the preference, type the following into /Applications/Utilities/Terminal.app:

defaults delete com.openvpn.tunnelblick XXX-useDownRootPlugin

where XXX is the name of your configuration as it is displayed when you click the Tunnelblick icon or in the Details… window. (Usually that is the name of the configuration file without the extension, but it can be different if you have configurations in subfolders.)

The preference was originally set because the user checked the "Do not ask me again" checkbox when Tunnelblick popped up a window asking if the plugin should be used. Thinking about it, Tunnelblick should ignore the preference - and not use the plugin -- if there are no user/group options in the configuration file. I'll put that on my to do list.

[jkbull...gmail.com]

Oh, and the "Kext foo.tun not found for unload request." can be ignored; it doesn't affect anything.

[Michael Demmer]

> I'm sorry your problem wasn't resolved earlier; sometimes I lose track.

No problem. It wasn't actually impeding anything for me.

Thanks for the info -- that seems to have done the trick, though for
some odd reason I don't actually see any info that that WINS settings
are being changed (which I would have expected). But in any event,
this seems to work now with the unmodified leasewatch script.

-m

[Michael Demmer]

> Thanks for the info -- that seems to have done the trick, though for
> some odd reason I don't actually see any info that that WINS settings
> are being changed (which I would have expected). But in any event,
> this seems to work now with the unmodified leasewatch script.

Oops, looks like I spoke too soon. Now it looks like when the WINS
settings change, the connection is restarted, which is better than it
disconnecting but still far from ideal. Here's the log snippet:

2011-04-06 15:30:01 *Tunnelblick leasewatch: A network configuration

change was detected
* WINS configuration has changed:
* --- BEGIN EXPECTED WINS CFG ---
* <dictionary> {
* WINSAddresses : <array> {

* 0 : 888.16.0.30

* }
* Workgroup : FOOTECH
* }
* ---- END EXPECTED WINS CFG ----
*
* --- BEGIN CURRENT WINS CFG ---
* <dictionary> {
* NetBIOSName : mdemmer-mac
* WINSAddresses : <array> {

* 0 : 888.16.0.30

* }
* Workgroup : FOOTECH
* }
* ---- END CURRENT WINS CFG ----
*
* --- BEGIN PRE-VPN WINS CFG ---
* <dictionary> {
* TunnelblickNoSuchKey : true
* }
* ---- END PRE-VPN WINS CFG ----
* Sending USR1 to OpenVPN

(process ID 9887) to restart the connection.
2011-04-06 15:30:02 us=771583 event_wait : Interrupted system call (code=4)
2011-04-06 15:30:02 us=772301 TCP/UDP: Closing socket
2011-04-06 15:30:02 us=772375
/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh
-m -w -d tun0 1500 1542 888.18.132.30 888.18.132.29 restart
2011-04-06 15:30:02 us=884804 SIGUSR1[hard,] received, process restarting
2011-04-06 15:30:02 us=884902 MANAGEMENT:
>STATE:1302129002,RECONNECTING,SIGUSR1,,
2011-04-06 15:30:02 us=891847 MANAGEMENT: CMD 'hold release'
2011-04-06 15:30:02 us=892552 NOTE: the current --script-security

setting may allow this configuration to call user-defined scripts

2011-04-06 15:30:02 us=892600 Re-using SSL/TLS context
2011-04-06 15:30:02 us=892649 LZO compression initialized
2011-04-06 15:30:02 us=892776 Control Channel MTU parms [ L:1542 D:166

EF:66 EB:0 ET:0 EL:0 ]

2011-04-06 15:30:02 us=892829 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-04-06 15:30:02 us=892851 Data Channel MTU parms [ L:1542 D:1450

EF:42 EB:135 ET:0 EL:0 AF:3/1 ]

2011-04-06 15:30:02 us=892876 Local Options String: 'V4,dev-type

tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher
BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'

2011-04-06 15:30:02 us=892891 Expected Remote Options String:

'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto
UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize
128,tls-auth,key-method 2,tls-server'

2011-04-06 15:30:02 us=892910 Local Options hash (VER=V4): '504e774e'
2011-04-06 15:30:02 us=892928 Expected Remote Options hash (VER=V4): '14168603'
2011-04-06 15:30:02 us=892948 UDPv4 link local: [undef]
2011-04-06 15:30:02 us=892963 UDPv4 link remote: 999.70.196.28:1194
2011-04-06 15:30:02 us=893006 MANAGEMENT: >STATE:1302129002,WAIT,,,
2011-04-06 15:30:02 us=901270 MANAGEMENT: >STATE:1302129002,AUTH,,,
2011-04-06 15:30:02 us=901562 TLS: Initial packet from
999.70.196.28:1194, sid=26250ed5 3fc1ee69
2011-04-06 15:30:02 us=953249 VERIFY OK: depth=1,
/C=US/ST=CA/L=SF/O=Foo_Technologies__Inc./CN=OpenVPN-CA/emailAddress=ad...@footech.com
2011-04-06 15:30:02 us=953610 VERIFY OK: nsCertType=SERVER
2011-04-06 15:30:02 us=953627 VERIFY OK: depth=0,
/C=US/ST=CA/O=Foo_Technologies__Inc./CN=server/emailAddress=ad...@footech.com
2011-04-06 15:30:02 *Tunnelblick client.down.tunnelblick.sh: Cancelled

monitoring of system configuration changes

2011-04-06 15:30:02 *Tunnelblick client.down.tunnelblick.sh: Restored

the DNS and WINS configurations

2011-04-06 15:30:03 us=90067 Data Channel Encrypt: Cipher 'BF-CBC'

initialized with 128 bit key

2011-04-06 15:30:03 us=90110 Data Channel Encrypt: Using 160 bit

message hash 'SHA1' for HMAC authentication

2011-04-06 15:30:03 us=90170 Data Channel Decrypt: Cipher 'BF-CBC'

initialized with 128 bit key

2011-04-06 15:30:03 us=90185 Data Channel Decrypt: Using 160 bit

message hash 'SHA1' for HMAC authentication

2011-04-06 15:30:07 us=670900 Control Channel: TLSv1, cipher

TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

2011-04-06 15:30:07 us=670971 [server] Peer Connection Initiated with
999.70.196.28:1194

Any help would be appreciated. Thanks.

-m

[jkbull...gmail.com]

leasewatch sees the

NetBIOSName : mdemmer-mac

and thinks that is enough of a change to restart the connection.

I assume the connection is actually restarting successfully -- the log extract you posted doesn't show it going all the way through to a completed connection.

Or do you mean it just restarts over and over and over?

I plan to add options to control what causes a restart, but that won't help you much until I commit the changes (and probably until I do another beta release) -- and you'd have to use the beta (which is apparently pretty stable, though).

[Michael Demmer]

Unfortunately it restarts over and over. So it seems that my best bet
is to keep the leasewatch hack until there's an option to not monitor
WINS changes.

-m