github-starred/barrier
2
0
Fork 0
mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00
Code Issues 1.0k Projects Packages Wiki Activity Actions

[GH-ISSUE #773] Barrier server fails to start when IPv6 is disabled on the Linux host system (ipv6.disable=1) #607

New issue
Open
opened 2026-05-05 06:46:19 -06:00 by gitea-mirror · 10 comments
gitea-mirror commented 2026-05-05 06:46:19 -06:00
Owner
Copy link

Originally created by @cryzed on GitHub (Jun 26, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/773

Originally assigned to: @shymega on GitHub.

Operating Systems

Server: Arch Linux (up-to-date, KDE Plasma, Xorg)

Client: Arch Linux ARM (up-to-date, irrelevant)

Barrier Version

2.3.2

Steps to reproduce bug

  1. Open "Barrier" GUI application
  2. Tick "Server" and leave radio button on "Configure interactively"
  3. Press "Start"

Other info

  • When did the problem start to occur? When I... started Barrier for the first time. I haven't used the application before.
  • Is there a way to work around it? No.
  • Does this bug prevent you from using Barrier entirely? Yes

The GUI application has the following log, repeating:

[2020-06-26T20:05:43] INFO: starting server
[2020-06-26T20:05:43] INFO: config file: /tmp/Barrier.PKtNKR
[2020-06-26T20:05:43] INFO: log level: INFO
[2020-06-26T20:05:43] ERROR: process exited with error code: 11
[2020-06-26T20:05:43] INFO: detected process not running, auto restarting

To get more information on what goes wrong, I ran the actually crashing component (barriers) manually, the way it is run by the GUI application, with the automatically generated config:

user@desktop ~ $ barriers -f --no-tray --debug DEBUG2 --name desktop --enable-crypto -c /tmp/Barrier.ikxkiR --address :24800                                                                                  
[2020-06-26T20:08:03] DEBUG: opening configuration "/tmp/Barrier.ikxkiR"
[2020-06-26T20:08:03] DEBUG: configuration read successfully
[2020-06-26T20:08:03] DEBUG1: starting server
[2020-06-26T20:08:03] DEBUG: XOpenDisplay(":0")
[2020-06-26T20:08:03] DEBUG1: thread 0x00000002 entry
[2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x00800009
...
[2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x07800004
[2020-06-26T20:08:03] DEBUG: xscreensaver window: 0x00000000
[2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x00800009
...
[2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x07800004
[2020-06-26T20:08:03] DEBUG: screen shape: 0,0 3840x1080 (xinerama)
[2020-06-26T20:08:03] DEBUG: window is 0x07800004
[2020-06-26T20:08:03] DEBUG: adopting new buffer
[2020-06-26T20:08:03] DEBUG: opened display
[2020-06-26T20:08:03] DEBUG1: registered event type error as 4
[2020-06-26T20:08:03] DEBUG1: registered event type suspend as 5
[2020-06-26T20:08:03] DEBUG1: registered event type resume as 6
[2020-06-26T20:08:03] DEBUG1: creating primary screen
Segmentation fault (core dumped)
Originally created by @cryzed on GitHub (Jun 26, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/773 Originally assigned to: @shymega on GitHub. ### Operating Systems ### Server: Arch Linux (up-to-date, KDE Plasma, Xorg) Client: Arch Linux ARM (up-to-date, irrelevant) ### Barrier Version ### 2.3.2 ### Steps to reproduce bug ### 1. Open "Barrier" GUI application 2. Tick "Server" and leave radio button on "Configure interactively" 3. Press "Start" ### Other info ### * When did the problem start to occur? When I... started Barrier for the first time. I haven't used the application before. * Is there a way to work around it? No. * Does this bug prevent you from using Barrier entirely? Yes The GUI application has the following log, repeating: ``` [2020-06-26T20:05:43] INFO: starting server [2020-06-26T20:05:43] INFO: config file: /tmp/Barrier.PKtNKR [2020-06-26T20:05:43] INFO: log level: INFO [2020-06-26T20:05:43] ERROR: process exited with error code: 11 [2020-06-26T20:05:43] INFO: detected process not running, auto restarting ``` To get more information on what goes wrong, I ran the actually crashing component (`barriers`) manually, the way it is run by the GUI application, with the automatically generated config: ``` user@desktop ~ $ barriers -f --no-tray --debug DEBUG2 --name desktop --enable-crypto -c /tmp/Barrier.ikxkiR --address :24800 [2020-06-26T20:08:03] DEBUG: opening configuration "/tmp/Barrier.ikxkiR" [2020-06-26T20:08:03] DEBUG: configuration read successfully [2020-06-26T20:08:03] DEBUG1: starting server [2020-06-26T20:08:03] DEBUG: XOpenDisplay(":0") [2020-06-26T20:08:03] DEBUG1: thread 0x00000002 entry [2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x00800009 ... [2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x07800004 [2020-06-26T20:08:03] DEBUG: xscreensaver window: 0x00000000 [2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x00800009 ... [2020-06-26T20:08:03] DEBUG2: can't read property 579 on window 0x07800004 [2020-06-26T20:08:03] DEBUG: screen shape: 0,0 3840x1080 (xinerama) [2020-06-26T20:08:03] DEBUG: window is 0x07800004 [2020-06-26T20:08:03] DEBUG: adopting new buffer [2020-06-26T20:08:03] DEBUG: opened display [2020-06-26T20:08:03] DEBUG1: registered event type error as 4 [2020-06-26T20:08:03] DEBUG1: registered event type suspend as 5 [2020-06-26T20:08:03] DEBUG1: registered event type resume as 6 [2020-06-26T20:08:03] DEBUG1: creating primary screen Segmentation fault (core dumped) ```
gitea-mirror added the
bug
help wanted
linux
 labels 2026-05-05 06:46:19 -06:00
gitea-mirror commented 2026-05-05 06:46:23 -06:00
Author
Owner
Copy link

@cryzed commented on GitHub (Jun 26, 2020):

I am pretty sure the segmentation fault occurs here. I made a debug release of Barrier which also just showed that the last log line before the segfault was "creating primary screen" here. It feels like Barrier fails to open the display ":0" (which is the correct display), because when I set a custom display ":1" it doesn't crash:

user@desktop ~ $ barriers -f --no-tray --debug DEBUG2 --name desktop --display ":1" --enable-crypto -c /tmp/Barrier.iRtbNR --address :24800                                                                                    
[2020-06-26T21:24:32] DEBUG: opening configuration "/tmp/Barrier.iRtbNR"
[2020-06-26T21:24:32] DEBUG: configuration read successfully
[2020-06-26T21:24:32] DEBUG1: starting server
[2020-06-26T21:24:32] DEBUG: XOpenDisplay(":1")
[2020-06-26T21:24:32] DEBUG1: thread 0x00000002 entry
[2020-06-26T21:24:32] DEBUG: retry in 60 seconds
[2020-06-26T21:24:32] DEBUG1: registered event type reloadConfig as 4
[2020-06-26T21:24:32] DEBUG1: registered event type forceReconnect as 5
[2020-06-26T21:24:32] DEBUG1: registered event type resetServer as 6
[2020-06-26T21:24:32] DEBUG: event queue is ready
[2020-06-26T21:24:32] WARNING: primary screen unavailable: unable to open screen

I also checked with xhost if I have some too restrictive access controls set for the display, but I don't -- I even went so far as to set it temporarily to xhost + (allow any and all connections), but it's the same result.

Of course that's useless in the end. Is there something else I can do to make fixing this easier for you guys and girls?

<!-- gh-comment-id:650355785 --> @cryzed commented on GitHub (Jun 26, 2020): I am pretty sure the segmentation fault occurs [here](https://github.com/debauchee/barrier/blob/master/src/lib/barrier/ServerApp.cpp#L609). I made a debug release of Barrier which also just showed that the last log line before the segfault was "creating primary screen" [here](https://github.com/debauchee/barrier/blob/master/src/lib/barrier/ServerApp.cpp#L611). It feels like Barrier fails to open the display ":0" (which is the correct display), because when I set a custom display ":1" it doesn't crash: ``` user@desktop ~ $ barriers -f --no-tray --debug DEBUG2 --name desktop --display ":1" --enable-crypto -c /tmp/Barrier.iRtbNR --address :24800 [2020-06-26T21:24:32] DEBUG: opening configuration "/tmp/Barrier.iRtbNR" [2020-06-26T21:24:32] DEBUG: configuration read successfully [2020-06-26T21:24:32] DEBUG1: starting server [2020-06-26T21:24:32] DEBUG: XOpenDisplay(":1") [2020-06-26T21:24:32] DEBUG1: thread 0x00000002 entry [2020-06-26T21:24:32] DEBUG: retry in 60 seconds [2020-06-26T21:24:32] DEBUG1: registered event type reloadConfig as 4 [2020-06-26T21:24:32] DEBUG1: registered event type forceReconnect as 5 [2020-06-26T21:24:32] DEBUG1: registered event type resetServer as 6 [2020-06-26T21:24:32] DEBUG: event queue is ready [2020-06-26T21:24:32] WARNING: primary screen unavailable: unable to open screen ``` I also checked with `xhost` if I have some too restrictive access controls set for the display, but I don't -- I even went so far as to set it temporarily to `xhost +` (allow any and all connections), but it's the same result. Of course that's useless in the end. Is there something else I can do to make fixing this easier for you guys and girls?
gitea-mirror commented 2026-05-05 06:46:26 -06:00
Author
Owner
Copy link

@cryzed commented on GitHub (Jun 26, 2020):

Turns out the cause was me disabling IPv6 on the kernel commandline (ipv6.disable=1), @shymega figured this out on the IRC channel. When Barrier wants to listen for clients, it assumes IPv6 is enabled/exists and crashes when it isn't.

<!-- gh-comment-id:650366704 --> @cryzed commented on GitHub (Jun 26, 2020): Turns out the cause was me disabling IPv6 on the kernel commandline (`ipv6.disable=1`), @shymega figured this out on the IRC channel. When Barrier wants to listen for clients, it assumes IPv6 is enabled/exists and crashes when it isn't.
gitea-mirror commented 2026-05-05 06:46:28 -06:00
Author
Owner
Copy link

@shymega commented on GitHub (Jun 26, 2020):

This bug is confirmed. Barrier currently assumes that every machine the server is on has both AF_INET and AF_INET6 available as address families. Obviously, this cannot continue. Work must commence when possible to add a configuration option to both the file & GUI to restrict address families to IPv4, IPv6, both, or either.

For now, the solution is to keep IPv6 enabled.

<!-- gh-comment-id:650379925 --> @shymega commented on GitHub (Jun 26, 2020): This bug is confirmed. Barrier currently assumes that every machine the server is on has both `AF_INET` and `AF_INET6` available as address families. Obviously, this cannot continue. Work must commence when possible to add a configuration option to both the file & GUI to restrict address families to IPv4, IPv6, both, or either. For now, the solution is to keep IPv6 enabled.
gitea-mirror commented 2026-05-05 06:46:31 -06:00
Author
Owner
Copy link

@sourya7 commented on GitHub (Jul 1, 2020):

FWIW, I encountered the same bug. I had ipv6 disabled because turns out that was leaking my vpn connections and did not feel like re-enabling it just to make barrier work. The workaround for me was to use ipv6.disable_ipv6=1 kernel parameter vs the ipv6.disable=1 parameter. The latter disables the whole stack and the former just makes it so that we don't assign any network address to the interfaces. This works as intended for me. Barrier seems to work without crashing and I don't have connection leaks over ipv6.

<!-- gh-comment-id:652466425 --> @sourya7 commented on GitHub (Jul 1, 2020): FWIW, I encountered the same bug. I had ipv6 disabled because turns out that was leaking my vpn connections and did not feel like re-enabling it just to make barrier work. The workaround for me was to use `ipv6.disable_ipv6=1` kernel parameter vs the `ipv6.disable=1` parameter. The latter disables the whole stack and the former just makes it so that we don't assign any network address to the interfaces. This works as intended for me. Barrier seems to work without crashing and I don't have connection leaks over ipv6.
gitea-mirror commented 2026-05-05 06:46:33 -06:00
Author
Owner
Copy link

@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:694597004 --> @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.
gitea-mirror commented 2026-05-05 06:46:35 -06:00
Author
Owner
Copy link

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

Let's not close valid bugs without a valid reason.

<!-- gh-comment-id:757533312 --> @p12tic commented on GitHub (Jan 10, 2021): Let's not close valid bugs without a valid reason.
gitea-mirror commented 2026-05-05 06:46:37 -06:00
Author
Owner
Copy link

@agilleyrh commented on GitHub (Feb 2, 2021):

Also having this issue after disabling IPv6.

<!-- gh-comment-id:771926752 --> @agilleyrh commented on GitHub (Feb 2, 2021): Also having this issue after disabling IPv6.
gitea-mirror commented 2026-05-05 06:46:39 -06:00
Author
Owner
Copy link

@shymega commented on GitHub (Feb 3, 2021):

Let's not close valid bugs without a valid reason.

Apologies on the bot's behalf.

<!-- gh-comment-id:772874711 --> @shymega commented on GitHub (Feb 3, 2021): > Let's not close valid bugs without a valid reason. Apologies on the bot's behalf.
gitea-mirror commented 2026-05-05 06:46:41 -06:00
Author
Owner
Copy link

@shymega commented on GitHub (Feb 3, 2021):

Also having this issue after disabling IPv6.

After disabling IPv6? How did you disable it? A kernel param? I know its not ideal right now, but disabling it in the networking stack "works"™️ for now...sorry :/ - hopefully a fix will come soon.

<!-- gh-comment-id:772875311 --> @shymega commented on GitHub (Feb 3, 2021): > Also having this issue after disabling IPv6. _After_ disabling IPv6? How did you disable it? A kernel param? I know its not ideal right now, but disabling it in the networking stack "works":tm: for now...sorry :/ - hopefully a fix will come soon.
gitea-mirror commented 2026-05-05 06:46:43 -06:00
Author
Owner
Copy link

@agilleyrh commented on GitHub (Feb 4, 2021):

I had disabled it via grub, I did this because of a networking issue that ended up being unrelated to IPv6 but when I went to configure Barrier, I ran into this. I have since re-enabled IPv6 so it's working.

<!-- gh-comment-id:773462573 --> @agilleyrh commented on GitHub (Feb 4, 2021): I had disabled it via grub, I did this because of a networking issue that ended up being unrelated to IPv6 but when I went to configure Barrier, I ran into this. I have since re-enabled IPv6 so it's working.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
enhancement/builds/windows-multi-versions-build
martin-furter-barrier-term
enhancement/builds/macos-universal
enhancement/builds/macos-universal-qt6-test
2.3.x
fix/lang-translation/ssl-slash-tls
feature/build/compile/32-bit
feature/build/compile/armv7
testing-framework
README-update
remotes/fork/README-update
remotes/fork/smartzeroconf
smartzeroconf
pages-devel
remotes/fork/pages-devel
pkgconfig
remotes/fork/pkgconfig
release
remotes/fork/release
v2.4.0
v2.3.4
v2.3.3
1.11.0-stable
v1.11.0-rc2
v2.3.2
v1.10.3-stable
v2.3.2-alpha
v2.3.1
v2.3.0
v1.10.2-stable
v1.10.2-rc1
v1.10.2-rc2
v2.1.2
v2.0.8-beta
v2.0.7-beta
v2.0.4-beta
v2.0.3-beta
v2.1.1
v2.1.0
v1.9.1-stable
v2.0.0
v1.9.0-stable
v2.0.0-RC2
v2.0.0-RC1
v2.0.0-stable
v1.8.8-stable
v1.8.7-stable
v1.8.6-stable
v1.8.5-stable
v1.8.4-stable
v1.8.3-stable
v1.8.1-stable
v1.8.0-beta
v1.7.3-stable
v1.7.2-stable
v1.7.1-stable
1.7.0
1.6.3-final
1.6.2
1.6.1
1.6.0
Labels
Clear labels   
HiDPI

   
bounty

   
bsd/freebsd

   
bsd/openbsd

   
bug

   
bug

   
build-infra

   
cantfix

   
critical

   
doc

   
duplicate

   
enhancement

   
fix-available

   
from git

   
from release

   
good first issue

   
help wanted

   
installer/package

   
invalid

   
linux

   
macOS

   
meta

   
needs testing

   
pull-request

Mirrored from GitHub Pull Request

  
query

   
question

   
regression

   
regression

   
v2.4.0

   
windows

   
wontfix

   
work-in-progress
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#607
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?