Bug 8521 - Local servers fail with "Connection to server timed out" on macOS
Summary: Local servers fail with "Connection to server timed out" on macOS
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-18 09:36 CET by Pierre Ossman
Modified: 2025-03-26 10:24 CET (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2025-02-18 09:36:56 CET
We're seeing a bunch of incorrect "Connection to server timed out" on macOS when connecting to a server that's on the same network as the macOS client.

The logs show that the error code we get is EHOSTUNREACH:

> 2025-02-18T09:27:47: ssh[E]: ssh: connect to host lab-132 port 22: No route to host
> 2025-02-18T09:27:47: ssh[E]: CONNECT ERROR: 65

This is fake as the machine is up, and we can connect to it just fine using ssh on the terminal.
Comment 1 Pierre Ossman cendio 2025-02-18 09:43:24 CET
This seems to be a new feature in macOS 15 that is just incredibly buggy. They've added a new "Local Network" permission that blocks access to resources on the same network.

It is supposed to pop up a dialog when an application tries a blocked access, so the user can approve it. But that is very unreliable. And even once you have approved the application, it is very unreliable that the application is actually unblocked.

They also haven't yet fixed so you can reset the system for testing. Apple recommends running a VM, or creating a new test user.

I can find a bunch of reports about this affecting Firefox and Chrome, so it is a general issue.

Here is a Firefox report that is closed as they consider it an Apple issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=1919889

And here is Apple's documentation for how it's supposed to work:

https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy
Comment 2 Pierre Ossman cendio 2025-02-18 09:44:37 CET
I can see that there are multiple "ThinLinc Client" entries under "Privacy & Security" => "Local Network". I've seen some claims that this is part of when things break down.

I'm also seeing multiple entries for Chrome in the same place. So it's not a ThinLinc specific problem.
Comment 3 Pierre Ossman cendio 2025-02-18 10:09:28 CET
It is unclear what triggers the issue, or resolves it. A reboot seems to get things working for a while at least.
Comment 4 Pierre Ossman cendio 2025-03-05 14:22:06 CET
A reboot isn't really reliable. After a short while, it stops working again. I suspect it might take a short while for the blocking system to boot up, and it works until then.
Comment 5 Pierre Ossman cendio 2025-03-05 14:23:33 CET
I've filled bug report FB16734000 using macOS Feedback Assistant.
Comment 6 Pierre Ossman cendio 2025-03-05 14:45:04 CET
It might be a signature issue. I tried the official 4.18.0 bundle, which gave me a prompt (even though ThinLinc Client was already listed in the privacy settings).

After clicking yes to that prompt, and trying again, the client was now able to connect.

Switching back and forth between an unsigned jenkins build, and the 4.18.0 client, reliably gives me an issue with the unsigned build, and works with the 4.18.0 build.

We saw something similar when testing to use accessibility functions for keyboard grab. You could not mix signed and unsigned applications in that case. See bug 4660, comment 12.
Comment 7 Pierre Ossman cendio 2025-03-07 16:35:17 CET
One interesting note is that when I removed all copies of the ThinLinc client, then one of the entries under "Privacy & Security" => "Local Network" for tlclient can be seen as turned off, and it's not possible to change it (most entries won't change though).

This hidden setting could be what is blocking things.

I'm unsure if this entry was previously hidden, or if it was one of the existing entries that changed state. I didn't keep a list before and after removing the clients to compare.

(There is also the odd behaviour that it doesn't forget about the client after all copies have been removed. But I think Apple documented that this is a known bug with the new "Local Network" check)
Comment 8 Pierre Ossman cendio 2025-03-10 16:22:40 CET
After wiping all copies of ThinLinc, rebooting, and installing the signed 4.18.0 version again, we're unfortunately back to a wedged state. This time with the signed client not working again. :/

Installing a development build, that now has a different bundle id, works fine, though.
Comment 9 Pierre Ossman cendio 2025-03-10 16:32:04 CET
I've managed to find where macOS stores the configuration for this:

/Library/Preferences/com.apple.networkextension.plist

If I toggle the permissions in the Settings UI, then I can see the values in this plist change.

Note that this is a global file, not a per user one. I can not see any field that links this to a specific user. So it might be a complete lie from Apple that this setting is per user.

Given the fields in the file, I was also able to find this code that seems to show how things are implemented:

https://git.saurik.com/apple/mdnsresponder.git/blame/19fa75a9b9d0f880da91504945516a17ce09a2fb:/mDNSMacOSX/mdns_objects/mdns_trust_checks.m#l340

In short, MulticastPreferenceSet controls if the user has been queried, and DenyMulticast if the application should be blocked or not.

We could try removing this file to reset everything. I can find some references that this can be done from recovery mode.
Comment 10 Pierre Ossman cendio 2025-03-10 17:08:56 CET
Removing the file seems to work well. The list is now empty in Settings, and com.apple.networkextension.plist is rebuilt with all applications found on the system but with all settings in their default values.

Starting a signed 4.18.0 client initially fails, and gives a popup asking to allow it. After allowing it, it can then proceed.

The same thing happens with an unsigned development build.

After that, I now have two independent entries in Settings.
Comment 11 Pierre Ossman cendio 2025-03-11 13:35:07 CET
I just got a duplication for the TigerVNC 1.14.1 and TigerVNC 1.15.0 bundles. No idea why. Both bundles have the same id. Both bundles are signed by the same certificate. Both bundles are unmodified (confirmed by codesign).

What I can see in the database is the original entry is still in place. It has just the id (com.tigervnc.tigervnc). At the end of the list, a new entry has shown up with not just the id, but also the path to the second bundle.
Comment 12 Pierre Ossman cendio 2025-03-11 13:36:06 CET
Upstream report:

https://github.com/TigerVNC/tigervnc/issues/1912

Note You need to log in before you can comment on or make changes to this bug.