Connecting notebook to remote kernel

I'm trying to connect my FrontEnd session to remote kernel. Manual connection works by creating LinkObject like so:

link = LinkCreate["8000@127.0.0.1,8001@127.0.0.1", LinkMode -> Listen, LinkProtocol -> "TCPIP"]


Connect to remote machine forwarding ports 8000 and 8001:

ssh -R8000:127.0.0.1:8000 -R8001:127.0.0.1:8001 user@host


Run:

wolfram -wstp -LinkMode Connect -LinkProtocol TCPIP -LinkName 8000@127.0.0.1,8001@127.0.0.1


Then locally this works as expected:

LinkRead[link]
(*InputNamePacket["In[1]:= "]*)

LinkWrite[link, Unevaluated@EvaluatePacket[$MachineName]] LinkRead[link] (*ReturnPacket["remote_machine_name"]*)  But any attempt to connect my FrontEnd results in a frozen evaluating cell that doesn't return anything. Even though the connection is clearly there, because it drops remotely after closing it locally. I've tried many things: Evaluation -> Kernel Configuration Options, the tunnel.sh script suggested in other answers, assigning to $ParentLink, nothing works!

Remote machine has linux with Wolfram Engine For Developers installed. And I'm running WolframDesktop 12.0 locally on Mac.

EDIT: I've managed to get it working with Raw MathLink connection option ("RawMathLinkProgram" -> True). But it's pretty limited, no graphics, just text output.

EDIT: Suprisingly it works if I connect to my other laptop within my home network. It also has Ubuntu and docker with Wolfram Engine. But if I try basically the same steps with a cloud server, it refuses to work (unless it's raw mathlink connection).

Reverse connection:

ssh -L8000:127.0.0.1:8000 -L8001:127.0.0.1:8001 user@host


Replace Connect with Listen

wolfram -wstp -LinkMode Listen -LinkProtocol TCPIP -LinkName 8000@127.0.0.1,8001@127.0.0.1


And local Kernel Configuration:

-LinkMode Connect -LinkProtocol TCPIP -LinkName 8000@127.0.0.1,8001@127.0.0.1


Same result, local FrontEnd just crashes if I connect to remote cloud machine, but works with my laptop (shrug)

Very certain that it's a bug at this point, some low level protocol discrepancies maybe.

• I would be surprised if this works when you try to use a "Wolfram Engine for Developers" which I interpret as being the "free Wolfram Kernel". AFAIK, the free version comes explicitly without a front end because you are not allowed to use one. The easiest way to test this is to make a "remote" kernel which uses an ssh to your current machine where you have a real kernel. If this works, chances are good that indeed the free version kernel actively prevents you from connecting with a FE. – halirutan Nov 4 '19 at 0:24
• @halirutan Connecting to local free kernel works fine, so it's not limited to running only without front end. It must be something else, no idea what. – swish Nov 4 '19 at 0:36
• But your "local free kernel" might be backed by a real license. Can you check your \$ActivationKey for your local free kernel and ensure that it doesn't use your bought license? – halirutan Nov 4 '19 at 0:42
• @halirutan No, I'm pretty sure, it is running from a docker container. – swish Nov 4 '19 at 0:57
• swish, I just reproduced the exact same behavior in 12.1.1. Front-end links up with cloud kernel only with "Raw MathLink connection" checked. Closing the kernel closes the remote connection. I'm running the same license on both ends (allowed by policy). Have you figured out any further steps? – flamo Aug 1 '20 at 4:39

Sorry this is not an answer but the text goes too long for the comment.

There'a whole bunch of things that could go wrong with remote kernels in my experience.

Basically FE starts remote kernel and asks it to connect to the FE, passing FE addresses and ports in the link parameters. In my case the remote command line looks like:

WolframKernel -wstp -LinkMode Connect -LinkProtocol TCPIP -LinkName 61517@10.0.0.3,61518
@10.0.0.3

The ports (61517 & 61518) are randomly chosen by the FE so it's hard to really use reverse forwarding via ssh (tunnel.sh tries to do this by parsing command line options. I was unable to make it work though).

Please note the reverse address (10.0.0.3 in my case) that the kernel should be able to connect to. It's not always the case so check if it is accessible from the machine where the remote kernel runs.

Even if you have not an ssh link but the full blown VPN connection to the remote system there can be another interesting problem:

The reverse address is chosen by FE using some heuristic and is based on the address on a remote machine:

FEEvaluate@FEPrivateFindBestInterfaceForDestination[hostname_or_ipaddr_as_string]