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

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

Connect to remote machine forwarding ports 8000 and 8001:

ssh -R8000: -R8001: user@host


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

Then locally this works as expected:

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

LinkWrite[link, Unevaluated@EvaluatePacket[$MachineName]]


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: -L8001: user@host

Replace Connect with Listen

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

And local Kernel Configuration:

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

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.

  • $\begingroup$ 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. $\endgroup$ – halirutan Nov 4 at 0:24
  • $\begingroup$ @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. $\endgroup$ – swish Nov 4 at 0:36
  • $\begingroup$ 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? $\endgroup$ – halirutan Nov 4 at 0:42
  • $\begingroup$ @halirutan No, I'm pretty sure, it is running from a docker container. $\endgroup$ – swish Nov 4 at 0:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.