OS X: Nothing received from server on UDP port 60003 #1254
Comments
|
Please re-try using the Please re-open if you continue to have issues, and also please if macOS is the client or the server or both. |
|
macOS is the client and server, just trying to get a connection over my LAN ip on the same machine to work. It's not a speed issue, I'm able to do it with localhost and my LAN ip 192.168.0.200 all within 1 minute. I'm happy to record it to prove that's not the case. Tried with the Localhost works. Using my current local ip does not, which should point to the same machine: Gives me the same error as above. Lastly, I cannot reopen this ticket, I don't have any UI options to do that. |
|
It sounds like you have an issue with your firewall if a specific IP does not work. I also tried to reproduce this with a default-config Mac (Ventura 13.2) and could not. I did have to enable remote login in the Sharing pane. Have you confirmed that 192.168.0.200 is the correct IP? Can you paste the output of |
Already disabled it, as that seemed like a common issue.
Again, used netcat to listen on UDP 60003 and was able to receive messages across 192.168.0.200 from the same machine, and other devices on the network. So doesn't appear to be a firewall issue. ifconfig: |
|
It looks like you have 2 connections active in the same subnet -- one with IP address 192.168.0.169 and the other with 192.168.0.200. Can you try disabling the .169 one and re-trying? |
|
Disabled wifi, the 192.168.0.169 interface, and ran: Same issue unfortunately |
|
Did the netcat test again and was able to receive the message |
|
Can you run You should see something like Also, out of curiosity, do you have any VMs or VPNs running on this machine? I'm only asking because both of those things could potentially mess with routing tables in weird ways, but that is admittedly inconsistent with nc working. Also, I will quickly mention that the error message you're getting from mosh-client is that it's not heard anything back from the mosh server, while your |
|
Also, another silly question: do you have anything in your ~/.ssh/config? |
|
mosh-server and lsof Current ssh config |
|
I believe ControlMaster is causing you problems. Can you try |
|
|
Did you perhaps make a typo? it's |
|
Sorry the typo was with my reply. Pasted it from your reply to run it. Thanks for trying at least, I'm stumped as well.
Capture output: |
|
From the packet capture, we can see that the mosh-client is in fact trying to contact the mosh-server, but it never replies. If this were linux, I'd say to strace mosh-server and see what it's doing, but unfortunately, this is macOS, and I don't know dtrace/dtruss well enough to form a useful suggestion. It really does seem like there's something weird with your network. It feels like a firewall dropping the packets. The packets are small, so it isn't something like an MTU issue (not that that should be a problem locally). This is what it should the tcpdump should look like: so just in case you were wonder if the bad cksum is a problem, it's not, that's just a sign of checksum offloading to the NIC. Just to confirm, while you were doing this, there was a mosh-server running? And it was on the port that you see in the pcap? The lsof commands from before should help you confirm this. Another experiment to do is to get a packet capture of your |
|
Tried both running
It's possible it's a networking issue, but why does netcat work and receive messages correctly? |
|
That was the dump from running the |
|
Without a tcpdump to compare, it's hard to say. But as I mentioned before, your netcat is testing the opposite datastream, we don't actually know for certain it works. localhost working doesn't necessarily mean a firewall issue is not happening, as firewalls can and do consider input/output interfaces. |
|
Edit: Netcat test with tcpdump results are above Archer A7 Router: System Settings: Also tried |
|
Tried running the nc server from an ssh connection, created a new tab in blink shell and wrote to the 192.168.0.200 60003 port and that also worked, at least in terms of seeing that message. Definitely at a loss on this one |
|
The router on your firewall is not related. The macOS firewall could be, especially since you have a VPN installed. I know it says inactive, but something is definitely weird here. Can you try connecting to your MBP from a different device using mosh? |
|
That was how I started, I was trying to use mosh to connect from a tablet to my mbp using blink shell but I kept getting that same issue, that's when I started pursuing trying to connect to the mbp from itself to test\debug. |
|
Any progress on this? I’m having the same issue trying to connect from Blink On an iPad -> MacOs Ventura |
|
The developers have no way to reproduce this. I cannot reproduce this on my Macbook Pro, and none of us have an iPad. So unfortunately progress here is unlikely to happen unless someone from the community figures it out. |
|
Thanks for the prompt reply! If I ever figure it out I'll post something. |
|
Reporting the same issue here (on two different machines), although at least |
|
@nburnett feel free to reach out to us on Blink issues. Not sure what would be going on here, but most of our users just need to add rules to their firewall. Leaving it here in case it helps (via rrgeorge): I have to run this every time i reboot: |
|
I think I might be experiencing the same issue currently. One thing I would like to point out, is in #1254 (comment) I seem to be experiencing the same challenge when connecting to the IPv4 address on the interface, but it connects fine when I use the IPv6 (automatically assigned) address. |
|
Whoa that might be it! Great find |
|
Took a few years but finally stumbled on a solution thanks to rrgeorge in the blink shell discord: #!/usr/bin/env bash
FW=/usr/libexec/ApplicationFirewall/socketfilterfw
MOSH=$(sudo -iu '#501' /usr/local/bin/brew info mosh|grep Cellar|awk '{print $1}')/bin/mosh-server
echo $MOSH
sudo $FW --add $MOSH
sudo $FW --unblockapp $MOSHFor some reason using the firewall cli makes a big difference compared to the Mac OS GUI Firewall settings to add the mosh-server binary. Unfortunately, I don't know why it works or what the difference is. There's also a few issues in blinkshell with identical solutions, just never found those before. |
|
This problem started happening to me after upgrading to Sequoia on my M2 Mini running Running Enabling the firewall and using the multiple scripts out there to add |
|
This seems to be an issue in Sequoia with mosh-server. It seems like UDP traffic is having issues in Sequoia, and apparently some VPNs, etc... have also been impacted by it. Firewalls are not related. And I can do a nc client-server on those ports just fine. I'm investigating on the Blink side to see what is going on and playing with the mosh-sever a bit (blinksh/blink#2054). Any pointers are welcome. |
|
I did a few other quick tests. So when running client-server, the client is not receiving back from mosh-server, but the server is receiving from the client. I traced a running mosh-server and started typing on the "non-receiving client": And from tcpdump, only traffic from Client to Server. I can see the heartbeats and keystrokes just going one way. Workaround: If connecting through Tailscale, things still work perfectly. This still looks like some firewall issue on Sequoia. |
|
We have found the issue in macOS Sequoia (thanks to @rrgeorge). The problem is due to the new Local Network Privacy feature, which was previously only on iOS but is now on macOS as well. Now, whenever apps access the local network, they prompt the user for permission, which is good for regular apps. However, since we're running mosh-server over an SSH connection, that prompt does not appear. We tested this in two ways:
To make this new privacy feature compatible with mosh-server, we face the challenge I don’t have any solutions right now, but any other ideas to bend this backwards and somehow trigger a prompt for mosh-server are welcome. This will affect macOS Sequoia users and force them to use Tailscale or something similar. I will reach out on the Apple developer forums to see if there’s anything I might have missed for CLI apps. |
I found this a comment on a thread from 2020 that may help. |
|
In my experiments, listening services only get triggered on a connection. I have a theory that if |
|
I am getting this error after upgrading to Sequoia 15.1 |
Reproduction
mosh-serverand got the following outputenv MOSH_KEY="SaHaHCFHl3b93sZkEsZDZA" mosh-client 192.168.0.200 60003Expected
The client should connect to the mosh-server and display my login shell
Actual
Instead it seems to make initial ssh connection, but the mosh connection hangs:
Environment
What I've tried
env MOSH_KEY="<key>" mosh-client 127.0.0.1 60003but not my local network IP like the example aboveAny help would be appreciated!
The text was updated successfully, but these errors were encountered: