SparkLabs Forum.

Community Help.


Viscosity Port Forwarding Applescript

James wrote:
Hi SpookyCow,

I'm afraid there isn't anything more that we can add that I haven't already mentioned.

What you're experiencing is a routing issue. Your VPN connection is most likely being routed into itself or packets to the VPN server are otherwise being prevented from leaving your computer. If the errors are occurring immediately after connecting then it points to a VPN configuration issue. If it's happening after being connected for a period of time then it points to something on your computer changing network settings that is having an impact on the connection. If it's the latter, and you've performed all of the troubleshooting steps to eliminate other software making changes, the only suggestion left I can offer is to backup all of your files and perform a clean install of macOS.

If an unsafe command is present in your configuration it will be listed in the error message in the log. Please see:
http://www.sparklabs.com/support/kb/art ... -detected/

Cheers,
James


The problem is the disconnects can happen within a minute or an hour. The only other app that even interacts with the network connection is Little Snitch. But, I've been using it just as long as I've been using Viscosity. And yes, the Little Snitch rules are setup correctly for the VPN/Viscosity connection. I just don't understand what changed Since Mac OS 11.x and/or Viscosity 1.6.7, which I could run overnight or days at a time without worrying about being disconnected. And not once had I ever saw a buffer error before then. The built in log doesn't report an errors about my OpenVPN commands, but I have to set Viscosity to allow unsafe commands. And every new version of a Mac OS release I actually do a clean install. Is there a way to enable a debug mode in Viscosity? Or is there somewhere I should be looking in the console logs to try and figure out what was going on?

Edit: I also wanted to let you know if I'm connected to the VPN and just idle or surfing, the disconnects don't occur. But, if I use almost full bandwidth that's when the disconnects really start happening. And I'm on a Fiber connection with a stable connection to my router.
Hi SpookyCow,

I'm afraid there is nothing further in the way of support we can offer - we've exhausted all options.

Regards,
James
James,

I just wanted to let you know that as of 10.12.4 beta 3 and 4, the frequent disconnects have stopped with Viscosity 1.6.8.

Thank you,

SpookyCow
James,

What in the world could be causing the "Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)"errors?

[code]Mar 18 19:48:44: Viscosity Mac 1.6.8 (1370)
Mar 18 19:48:44: Viscosity OpenVPN Engine Started
Mar 18 19:48:44: Running on Mac OS X 10.12.4
Mar 18 19:48:44: ---------
Mar 18 19:48:44: Checking reachability status of connection...
Mar 18 19:48:44: Connection is reachable. Starting connection attempt.
Mar 18 19:48:44: OpenVPN 2.3.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 14 2017
Mar 18 19:48:44: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Mar 18 19:48:47: UDPv4 link local: [undef]
Mar 18 19:48:47: UDPv4 link remote: [AF_INET]IP ADDRESS REMOVED:1197
Mar 18 19:48:48: [72fea75de9bc97b0536ae48f26a4d336] Peer Connection Initiated with [AF_INET]IP ADDRESS REMOVED:1197
Mar 18 19:48:50: Opening utun (connect(AF_SYS_CONTROL)): Resource busy
Mar 18 19:48:50: Opened utun device utun1
Mar 18 19:48:50: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mar 18 19:48:50: /sbin/ifconfig utun1 delete
Mar 18 19:48:50: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Mar 18 19:48:50: /sbin/ifconfig utun1 IP ADDRESS REMOVED mtu 1500 netmask 255.255.255.255 up
Mar 18 19:48:50: Initialization Sequence Completed
Mar 18 19:48:50: DNS mode set to: Full
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: Disconnecting due to "No buffer space available" errors.
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: write UDPv4: No buffer space available (code=55)
Mar 18 22:11:00: SIGTERM[hard,] received, process exiting

Edit: Why was this original post moved into a separate post I made?

I think I'll experiment with Tunnelblick and see if the same issues of frequent disconnects and crashes happen with Tunnelblick. I was originally a Tunnelblick user and thought the Viscosity Interface was better. But, not at the cost of having to sit here for 10-12 hours to make sure my transfers are being transferred. Clearly, something is going on and this happens regardless of which of the 30+ VPN servers I connect to. Plus, the last entry in the log shows that Viscosity is panicking and disconnecting.

Attachments

24 posts Page 3 of 3

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy