[GH-ISSUE #789] mac server, linux client: new client is unresponsive #623

Open
opened 2026-05-05 06:48:02 -06:00 by gitea-mirror · 5 comments
Owner

Originally created by @nmarasoiu on GitHub (Jul 10, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/789

Operating Systems

Server: MacOS Catalina (firewall off, SSL off in barrier)
Client: Ubuntu 20.04 LTS (firewall off)

Barrier Version

2.3.2

Steps to reproduce bug

configure server to have the client on the left, put the client hostname
configure server ip = the thunderbolt bridge ip
started server
configured client to server 169.254 thunderbolt ip
started client
telnet from client working to server ip 169.254.155.198 24800
client is "barrier is starting" for ever
pls see the logs below

trying with the ethernet IPs 192.168 instead of the thunderbolt ones is not different in any way.

Other info

  • When did the problem start to occur? From the start
  • Is there a way to work around it? No
  • Does this bug prevent you from using Barrier entirely? Yes

Logs:
[2020-07-10T21:27:17] DEBUG: Opening new socket: C4398D70
[2020-07-10T21:27:17] NOTE: accepted client connection
[2020-07-10T21:27:29] DEBUG: Opening new socket: C350DDE0
[2020-07-10T21:27:29] NOTE: accepted client connection
[2020-07-10T21:27:33] DEBUG: Opening new socket: C42042F0
[2020-07-10T21:27:33] NOTE: accepted client connection
[2020-07-10T21:27:45] DEBUG: Opening new socket: C4155A40
[2020-07-10T21:27:45] NOTE: accepted client connection
[2020-07-10T21:27:47] NOTE: new client is unresponsive
[2020-07-10T21:27:49] DEBUG: Opening new socket: C350ABB0
[2020-07-10T21:27:49] NOTE: accepted client connection

Originally created by @nmarasoiu on GitHub (Jul 10, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/789 ### Operating Systems ### Server: MacOS Catalina (firewall off, SSL off in barrier) Client: Ubuntu 20.04 LTS (firewall off) ### Barrier Version ### 2.3.2 ### Steps to reproduce bug ### configure server to have the client on the left, put the client hostname configure server ip = the thunderbolt bridge ip started server configured client to server 169.254 thunderbolt ip started client telnet from client working to server ip 169.254.155.198 24800 client is "barrier is starting" for ever pls see the logs below trying with the ethernet IPs 192.168 instead of the thunderbolt ones is not different in any way. ### Other info ### * When did the problem start to occur? From the start * Is there a way to work around it? No * Does this bug prevent you from using Barrier entirely? Yes Logs: [2020-07-10T21:27:17] DEBUG: Opening new socket: C4398D70 [2020-07-10T21:27:17] NOTE: accepted client connection [2020-07-10T21:27:29] DEBUG: Opening new socket: C350DDE0 [2020-07-10T21:27:29] NOTE: accepted client connection [2020-07-10T21:27:33] DEBUG: Opening new socket: C42042F0 [2020-07-10T21:27:33] NOTE: accepted client connection [2020-07-10T21:27:45] DEBUG: Opening new socket: C4155A40 [2020-07-10T21:27:45] NOTE: accepted client connection [2020-07-10T21:27:47] NOTE: new client is unresponsive [2020-07-10T21:27:49] DEBUG: Opening new socket: C350ABB0 [2020-07-10T21:27:49] NOTE: accepted client connection
gitea-mirror added the
macOS
bug
question
linux
labels 2026-05-05 06:48:02 -06:00
Author
Owner

@shymega commented on GitHub (Jul 10, 2020):

The IP address used is a link-local address. I do wonder if that's
having an effect.

Could you explain further about this 'Thunderbolt bridge'?

Thanks.

On this date - Fri, Jul 10, 2020 at 01:38:35PM -0700, nicu marasoiu wrote:

Operating Systems

Server: MacOS Catalina (firewall off, SSL off in barrier)
Client: Ubuntu 20.04 LTS (firewall off)

Barrier Version

2.3.2

Steps to reproduce bug

configure server to have the client on the left, put the client hostname
configure server ip = the thunderbolt bridge ip
started server
configured client to server 169.254 thunderbolt ip
started client
telnet from client working to server ip 169.254.155.198 24800
client is "barrier is starting" for ever
pls see the logs below

trying with the ethernet IPs 192.168 instead of the thunderbolt ones is not different in any way.

Other info

  • When did the problem start to occur? From the start
  • Is there a way to work around it? No
  • Does this bug prevent you from using Barrier entirely? Yes

Logs:
[2020-07-10T21:27:17] DEBUG: Opening new socket: C4398D70
[2020-07-10T21:27:17] NOTE: accepted client connection
[2020-07-10T21:27:29] DEBUG: Opening new socket: C350DDE0
[2020-07-10T21:27:29] NOTE: accepted client connection
[2020-07-10T21:27:33] DEBUG: Opening new socket: C42042F0
[2020-07-10T21:27:33] NOTE: accepted client connection
[2020-07-10T21:27:45] DEBUG: Opening new socket: C4155A40
[2020-07-10T21:27:45] NOTE: accepted client connection
[2020-07-10T21:27:47] NOTE: new client is unresponsive
[2020-07-10T21:27:49] DEBUG: Opening new socket: C350ABB0
[2020-07-10T21:27:49] NOTE: accepted client connection

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/debauchee/barrier/issues/789

--
Kind regards,
Dom Rodriguez (shymega)

<!-- gh-comment-id:656895639 --> @shymega commented on GitHub (Jul 10, 2020): The IP address used is a link-local address. I do wonder if that's having an effect. Could you explain further about this 'Thunderbolt bridge'? Thanks. On this date - Fri, Jul 10, 2020 at 01:38:35PM -0700, nicu marasoiu wrote: > ### Operating Systems ### > > Server: MacOS Catalina (firewall off, SSL off in barrier) > Client: Ubuntu 20.04 LTS (firewall off) > > ### Barrier Version ### > > 2.3.2 > > ### Steps to reproduce bug ### > configure server to have the client on the left, put the client hostname > configure server ip = the thunderbolt bridge ip > started server > configured client to server 169.254 thunderbolt ip > started client > telnet from client working to server ip 169.254.155.198 24800 > client is "barrier is starting" for ever > pls see the logs below > > trying with the ethernet IPs 192.168 instead of the thunderbolt ones is not different in any way. > > ### Other info ### > > * When did the problem start to occur? From the start > * Is there a way to work around it? No > * Does this bug prevent you from using Barrier entirely? Yes > > Logs: > [2020-07-10T21:27:17] DEBUG: Opening new socket: C4398D70 > [2020-07-10T21:27:17] NOTE: accepted client connection > [2020-07-10T21:27:29] DEBUG: Opening new socket: C350DDE0 > [2020-07-10T21:27:29] NOTE: accepted client connection > [2020-07-10T21:27:33] DEBUG: Opening new socket: C42042F0 > [2020-07-10T21:27:33] NOTE: accepted client connection > [2020-07-10T21:27:45] DEBUG: Opening new socket: C4155A40 > [2020-07-10T21:27:45] NOTE: accepted client connection > [2020-07-10T21:27:47] NOTE: new client is unresponsive > [2020-07-10T21:27:49] DEBUG: Opening new socket: C350ABB0 > [2020-07-10T21:27:49] NOTE: accepted client connection > > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/debauchee/barrier/issues/789 -- Kind regards, Dom Rodriguez (shymega)
Author
Owner

@nmarasoiu commented on GitHub (Jul 11, 2020):

Hi, sure, I am using a Thunderbolt 2 cable to connect to MBP laptops. Both Linux & MacOS support networking over thunderbolt, so they create a local link between them with between 3 and 8 Gbit/s and 0.5 ms latency (my tests) which i hope will provide benefits over the ethernet connection.

<!-- gh-comment-id:657007214 --> @nmarasoiu commented on GitHub (Jul 11, 2020): Hi, sure, I am using a Thunderbolt 2 cable to connect to MBP laptops. Both Linux & MacOS support networking over thunderbolt, so they create a local link between them with between 3 and 8 Gbit/s and 0.5 ms latency (my tests) which i hope will provide benefits over the ethernet connection.
Author
Owner

@nmarasoiu commented on GitHub (Jul 11, 2020):

However the same exact behaviour happened when i configured both client and server to use the Ethernet connection between them via the router. I will also repeat this test removing the cable between them, I am not sure if they still have the cable connected at that time.

<!-- gh-comment-id:657007372 --> @nmarasoiu commented on GitHub (Jul 11, 2020): However the same exact behaviour happened when i configured both client and server to use the Ethernet connection between them via the router. I will also repeat this test removing the cable between them, I am not sure if they still have the cable connected at that time.
Author
Owner

@github-actions[bot] commented on GitHub (Sep 18, 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.

<!-- gh-comment-id:694596949 --> @github-actions[bot] commented on GitHub (Sep 18, 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.
Author
Owner

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

Let's not close valid bug reports.

<!-- gh-comment-id:757536809 --> @p12tic commented on GitHub (Jan 10, 2021): Let's not close valid bug reports.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#623
No description provided.