New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nothing received from server on UDP port 60001 #374

gabrielecirulli opened this Issue Jan 16, 2013 · 15 comments


None yet

gabrielecirulli commented Jan 16, 2013

Hi, I have a server running Ubuntu 12.04 64bit and I compiled mosh on it, now I'm trying to connect to it from OS X (I used the pkg installer) but I get the following error:

Nothing received from server on UDP port 60001

I also ran iptables to allow traffic on port 60001 but to no avail. Could you please help me troubleshoot this problem?


This comment has been minimized.

akorn commented Jan 17, 2013

mosh-server is likely bound to the wrong IP. I have a similar problem. Please run

netstat -nulp | grep mosh

and check whether it's bound to the IP your client is expecting to talk to.

For example, I have a box I reach at, but mosh binds to a different IP:

udp        0      0 195.56.333.444:60001*                           1975/mosh-server

(IP obfuscated on purpose.)


This comment has been minimized.

akorn commented Jan 17, 2013

The problem seems to be that mosh gets the IP to bind to from the SSH_CONNECTION environment variable, which in my case contains the "wrong" IP (the primary IP of the host, but not the IP I use to reach it -- NAT is involved). Even with --server='/usr/bin/mosh-server new -i', it actually execs this:

execve("/usr/bin/mosh-server", ["/usr/bin/mosh-server", "new", "-i", "", "new", "-s", "-c", "8", "-l", "LANG=C", "-l", "LC_CTYPE=hu_HU.UTF-8", "--", "env", "SHELL=/bin/zsh", "screen", "-RD"], [/* 27 vars */]) = 0

This comment has been minimized.


keithw commented Jan 18, 2013

akorn: Yes, if you have a server-side NAT, this is not a configuration we really try to support yet. Sorry -- you may just want to remove the -s from your mosh Perl script.

gabrielecirulli: Can you please run nc -l -u 60001 on the server, and nc SERVERNAME -u 60001 on the client? If you type in to the client process, do you see this text on the server? If you then type into the server process, do you see this text on the client?


This comment has been minimized.

akorn commented Jan 18, 2013

Changing line 219 from

  my @server = ( 'new', '-s');


  my @server = ( 'new', '-i', '' );

fixed the problem for me. Thanks.


This comment has been minimized.

gabrielecirulli commented Jan 21, 2013

@keithw I tried running nc -l -u 60001 but it gave me the error UDP listen needs -p arg, so I added the -p argument and it looks like it started fine. If I try running nc myvps -u 60001 on my client, I get this error though (which I don't know how to address): nc: port range not valid. What should I do?


This comment has been minimized.

inhies commented Jan 29, 2013

I'm having the same problem. Using netcat as above to connect works fine, but mosh still complains about not being able to communicate and then it quits.

Edit: To add more info, it seems that perhaps mosh-server dies soon after starting when it's run as a regular user.

After running mosh-server new -v I get this as the last lines of output:

[mosh-server detached, pid = 28470]
forkpty: No such file or directory

/dev/pts IS mounted, though, so i am lost.


This comment has been minimized.

hatt commented Jun 3, 2013

I'm having this same issue although my server is a little bit strange in it's configuration. I connect to SSH over port 443, but it is locally proxied on the server to via SSLH. This confuses mosh from what I can see. The connection opens fine when I temporarily allowed port 443, so I suppose it is similar to the NAT issue above. Is it possible to get a a list of the mosh packet headers to add an SSLH rule for maybe? I'm not 100% sure if that would work but I imagine it could at least let me modify the SSH env vars for mosh to work.

@gabrielecirulli you need to put nc -u myvps 60001, netcat expects flags before the host/port.


This comment has been minimized.


keithw commented Jun 3, 2013

@hat: We think this is fixed in Git with the --bind-server=any option.


This comment has been minimized.

hatt commented Jun 3, 2013

Ah brilliant, did a HEAD installation and it appears to be fixed, thanks!


This comment has been minimized.

maciekish commented Feb 7, 2014

Hey, i just tried Mosh 1.2.4a (built from git today) and passed --bind-server=any and i still got the same issue. Server is Ubuntu 12.04 behind NAT and client is Mac OS 10.9.1 also behind NAT.

Both are updated to a fresh build from git of course.

EDIT: Forwarded port 60001 and passed -p 60001 as well. Everything working, case closed.


This comment has been minimized.

00001 commented Apr 19, 2015

I still have this issue with 1.2.4a on Ubuntu 14.04, on a remote machine behind NAT.

Using chrome extension on W7 to connect.

Port 22 and 60001 forwarded.

Edit: Got it working now. Turns out I had forwarded 60001 with TCP instead of UDP. Sorry!


This comment has been minimized.

ovizii commented Jun 11, 2015

When you guys are talking about port forwarding you mean on the server, right?


This comment has been minimized.

xinan commented Jan 25, 2017

@keithw I have this issue with mosh 1.2.5 on my digital ocean instance. I allowed mosh in ufw settings. However, it still fails to connect to 60001, but it can connect to 60002 onwards. With the nc command, I can see the text that I type on 60002 onwards, but nothing appears for port 60001. I am so confused.


This comment has been minimized.

MasonMoreland commented Nov 10, 2017

I'm still having an issue connecting through a NAT on my router. If I connect locally, I get in no problem. It's only when I go through the NAT that I fail to get mosh to come up, but ssh works fine.

Edit: Solved! All my fault. My port forwarding was only for TCP not TCP/UDP. Changing this setting fixed all of my problems.

Thanks for the software!


This comment has been minimized.

NotAFile commented May 15, 2018

I had similar issues using it over a VPN (wireguard). It turns out the issue was the providers CGNAT. Nothing I can do, it seems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment