github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #702] Catalina 10.5.5 mac mini can't client with a 10.15.4 mbp server #558

New issue

Open

opened 2026-05-05 06:40:45 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 06:40:45 -06:00

Owner

Originally created by @dan2bit on GitHub (May 28, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/702

Operating Systems

Server: macOS 10.15.4 (19E287) macbook Pro 16-inch, 2019

Client: macOS 10.15.4 (19E287) MacBookAir6,2
Client: macOS 10.15.5 (19F96) mac mini7,1

Barrier Version

2.3.2-Release-210c2b70

Steps to reproduce bug

macmini client will work for a period of time, and then will no longer respond, usually while I've been away from the client screen.
INFO log on server says [2020-05-28T15:53:50] INFO: zeroconf client detected: dan2mini but the client log endlessly times out trying to reach the server every 15 seconds
this persists through client reload, client stop+start, quit client application altogether and restart
the macbookair client is rock solid
IP addresses for the 3 machines are not changing, home wifi reaches all 3 and they are visible to each other in MacOS Network

Other info

When did the problem start to occur? When I first installed Barrier
Is there a way to work around it? Yes, I can stop barrier completely (quit app) on all three machines, start the server, and then start the two clients, and I get the macmini client back for a period of time
Does this bug prevent you from using Barrier entirely? Yes, eventually

Put anything else you can think of here.

When I try switching the mac mini to be the server, then I see the zeroconf client entries for both the laptops, but they get Connection refused errors from the mac mini. I assume there is some Catalina setting I'm missing, but the firewall is not on and I can do screen sharing and other kinds of macos network connections to and from the mini

The mac mini is running a plex server, perhaps there is a conflicting port grab that's invisible to me? Happy to help further diagnose as directed, I really want this to work.

Originally created by @dan2bit on GitHub (May 28, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/702 ### Operating Systems ### Server: macOS 10.15.4 (19E287) macbook Pro 16-inch, 2019 Client: macOS 10.15.4 (19E287) MacBookAir6,2 Client: macOS 10.15.5 (19F96) mac mini7,1 ### Barrier Version ### 2.3.2-Release-210c2b70 ### Steps to reproduce bug ### 1. macmini client will work for a period of time, and then will no longer respond, usually while I've been away from the client screen. INFO log on server says [2020-05-28T15:53:50] INFO: zeroconf client detected: dan2mini but the client log endlessly times out trying to reach the server every 15 seconds 2. this persists through client reload, client stop+start, quit client application altogether and restart 3. the macbookair client is rock solid 4. IP addresses for the 3 machines are not changing, home wifi reaches all 3 and they are visible to each other in MacOS Network ### Other info ### * When did the problem start to occur? When I first installed Barrier * Is there a way to work around it? Yes, I can stop barrier completely (quit app) on all three machines, start the server, and then start the two clients, and I get the macmini client back for a period of time * Does this bug prevent you from using Barrier entirely? Yes, eventually Put anything else you can think of here. When I try switching the mac mini to be the server, then I see the zeroconf client entries for both the laptops, but they get Connection refused errors from the mac mini. I assume there is some Catalina setting I'm missing, but the firewall is not on and I can do screen sharing and other kinds of macos network connections to and from the mini The mac mini is running a plex server, perhaps there is a conflicting port grab that's invisible to me? Happy to help further diagnose as directed, I really want this to work.

gitea-mirror commented

2026-05-05 06:40:48 -06:00

Author

Owner

@simons-public commented on GitHub (May 29, 2020):

@dan2bit I don't think it's a port conflict if you're using the defaults. By default barrier uses 24800 which I didn't see listed on any of the listed plex ports. It is possible that a duplicate process is running though, I have seen that happen with the Barrier GUI on Macs.

Can you post the logs on the mac mini client that's disconnecting?

@simons-public commented on GitHub (May 29, 2020): @dan2bit I don't think it's a port conflict if you're using the defaults. By default barrier uses 24800 which I didn't see listed on any [of the listed plex ports](https://support.plex.tv/articles/201543147-what-network-ports-do-i-need-to-allow-through-my-firewall/). It is possible that a duplicate process is running though, I have seen that happen with the Barrier GUI on Macs. Can you post the logs on the mac mini client that's disconnecting?

gitea-mirror commented

2026-05-05 06:40:51 -06:00

Author

Owner

@dan2bit commented on GitHub (May 29, 2020):

This is a very odd heisenbug. woke the mbp (server) this morning and all is running perfectly. attached the current client (macmini) log in case it's still useful, I will tail it and post a reply if it goes down again
barrier.log.txt

@dan2bit commented on GitHub (May 29, 2020): This is a very odd heisenbug. woke the mbp (server) this morning and all is running perfectly. attached the current client (macmini) log in case it's still useful, I will tail it and post a reply if it goes down again [barrier.log.txt](https://github.com/debauchee/barrier/files/4702011/barrier.log.txt)

gitea-mirror commented

2026-05-05 06:40:52 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 21, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 21, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:40:55 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

Let's not close this issue. It's one of the bugs that are hard to figure out and it makes sense to have a single place to collect this information instead of it being scattered across multiple bug reports.

@p12tic commented on GitHub (Jan 10, 2021): Let's not close this issue. It's one of the bugs that are hard to figure out and it makes sense to have a single place to collect this information instead of it being scattered across multiple bug reports.

No labels

Rows
Columns