Timbuktu Pro Fails on El Capitan 10.11.4 - Fixes?

[cau]

Timbuktu Pro was last updated in 2013 and discontinued by Arris a year ago. I have been using it for such a long time, so it is hard to give up and move on. I have been able to make Timbuktu Pro 8.8.5 work under El Capitan by installing it with SIP and Gatekeeper temporarily disabled during installation and configuration. I reenable SIP and Gatekeeper after that, and it just works (until 10.11.4). I always run it in secure mode (over SSH).

I just updated El Capitan to version 10.11.4 using the combo updater. Now, Timbuktu Pro no longer receives incoming control connections over SSH. Outbound connections (to Macs running Mavericks or Leopard) still work. I tried uninstalling and reinstalling Timbuktu Pro, but cannot make a connection to control the 10.11.4 Mac. Maybe OS X is blocking the connection, or Timbuktu cannot bind to SSH, or the Timbuktu Host process is not running or not listening. I am still searching for a reliable fix.

There must be a few people left who still use Timbuktu Pro. Has anybody found a way to make Timbuktu Pro work reliably as a host for incoming control connections?

 

[460works]

ssh -v (look at the man page for ssh) causes SSH to print debugging info.

Also, you might try adjusting the MTU for your network connection / hardware device:

In a Terminal.app window, run this 'networksetup' command:

$ networksetup -listallhardwareports

in order to find out what your devices are (egs. "en0", "en1").

Now run another 'networksetup' command:

$ networksetup -getMTU en0

in order to get the current MTU value for en0

and the similar, if applicable, for en1:

$ networksetup -getMTU en1

. . . you get the idea; and write down those values.

Then *try* / *test* your SSH connection attempts, with another MTU value (of 1424):

$ networksetup -setMTU en0 1424
$ networksetup -setMTU en1 1424

You will likely be prompted for your user account password.

You'd need to do that for every Mac, that are the Timbuktu parties, and on any Mac trying to connect to Timbuktu.

If tests fail, return the MTU settings back to what you wrote down.

All of which "help" I sort of doubt is helpful, now, because the odds are, that new Apple security policies are systemic throughout much of El Capitan . . . and Mac performance now relies upon other processes (other vendors) getting up to speed -and- their products getting up to speed.

PS. You might want to study the man page for 'networksetup', too.

-

 

[cau]

(... helpful suggestions to adjust MTU down to 1424 bytes, see above.)

Thank you for your advice.

Since I posted my plea for help, I was able to get it to work, but with issues. I got some replies on MacInTouch, but mostly figured it out for myself.

One suggestion was to remove the Gatekeeper quarantine on individual applications within Timbuktu. I did that.

See post 226192 on this page:
http://www.macintouch.com/readerreports/elcapitan/topic5037-013.html
or search for "item.226192 site:macintouch.com"

I am not sure that it was a Gatekeeper issue. The real problem appears to be on the client side. The Timbuktu client running under El Capitan version 10.11.5 will only make one connection. Any additional connection attempts fail. To make another connection, you must quit the Timbuktu application, then launch it again. I don't know why, but it works.

I also bought the (Apple) Remote Desktop application from the App Store. It works, but it is clearly focused on managing a collection of Macs in internal networks for classroom and business type Mac management. It does not like dealing with situations where the manager Mac frequently changes network addresses and environments, such as when the "manager" Mac is a laptop that may be inside the network or punching through the firewall (with different TCP/UDP ports for mildly improved security).

I looked at my MTU and it is currently 1500 bytes on the internal network. I will try the lower setting, just to see if it has anything to do with the "must restart the Timbuktu application for each separate connection" problem. I doubt it, but thank you VERY MUCH for taking the time to suggest it.

 

[460works]

More info from some old notes. This particular sentence reveals the gist of the MTU consideration:

"Each 1500 octet IP packet arriving on the Ethernet interface and to be forwarded over the PPPoE–IP interface must be fragmented into a 1492 octet fragment and a 28 octet fragment."​

The more that packets have to be fragmented, the more likely that fragments pile up, waiting to get thru the pipeline.

In the above example (MTU = 1500) you may guess that a 1492 octet IP packet would succeed without having to be fragmented. (Therefore, why not set MTU = 1492 from the get-go?)

Testing (using the 'ssh -v' suggestion and monitoring the firewall logs), I found that, with MTU = 1424 (I experimented with the range, 1400 - 1500), VPN problems vanished.

-