my PC (Linux/Lubuntu 18.04) and laptop (Linux/Lubuntu 20.04) are on the same network. I would like to use the keyboard and mouse of the PC also for the laptop - when both devices are running of course. For this I was hoping use the the programme “barrier” - version 2.3.2 - (which works just like “synergy”).
I set up and configured “barrier” on both devices but I couldn´t get it to work.
A first error(?) occurred when I wanted to configure barrier on the PC (server). The field after “SSL Fingerprint” remained empty. No idea why that is.
Nevertheless I tried to start barrier. I thought it wouldn´t work but the server said it was running!
Well, after that turned to to the client side.
Barrier definitely didn´t work here.
If I start it “Barrier is starting” is displayed below, but not “Barrier is running” (as it probably should).
If I send pings, both from the server and from the client, the other device in the network can be addressed with “0% packet loss” however.
So theoretically there shouldn´t be any problems as far as reachability within the network is concerned.
i had sworn off bluetooth because i never could get the connection to work all the way (pair=yes, trust=yes, connect=you wish!). after not getting any real idea from blueman or bluetoothctl about why things wouldn’t connect, i decided to start again with journalctl -f running in a terminal. luckily there i was able to see an error message that i was able to run a web search for which helped me enable some pulseaudio modules of all things.
*** WARNING *** The program 'barrier' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
Newer Ubuntus made a lot of breaking changes to their app system, so it wouldn’t surprise me if something like the avahi daemon was some too new version or something like that.
@01101111:
I see. But I don´t think my problem has anything to do with bluetooth as the connection of the two computers is established via the network.
Oh dear. Seems like there´s nothing much to be done about that now.
At first I thought it might be a general networking problem as I cannot get my PC to send files to the laptop via ssh either. Any attempts failed. So I was thinking along those lines too.
But your explanation makes more sense of course.
i didn’t make a very clear point point i wasn’t trying to compare the kind of networking used. i just meant that by watching journalctl when the connection process wasn’t working i was able to see the errors that neither bluetooth program was sharing with me.
my thought was that if you watched journalctl -f while starting barrier, you might see an error similar to the one (or different, but hopefully in some way helpful) that Akito posted.
@Akito and @01101111:
Thanks to both of you for your really fast responses.
First of all I can send you the answer to the network diagnostics demanded by @Akito .
Hopefully they are what you wanted to know.
ip a :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether c0:3f:d5:06:bf:be brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:7c:8c:cb brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:7c:8c:cb brd ff:ff:ff:ff:ff:ff
5: wlxe4beed63ad6d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:be:ed:63:ad:6d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.50/24 brd 192.168.2.255 scope global noprefixroute wlxe4beed63ad6d
valid_lft forever preferred_lft forever
inet6 2003:f3:f704:b800:f58b:fd5e:a213:1307/64 scope global dynamic noprefixroute
valid_lft 13753sec preferred_lft 1153sec
inet6 fde2:8acd:e9d3:0:322a:1b9f:e5a4:212a/64 scope global dynamic noprefixroute
valid_lft 86373sec preferred_lft 14373sec
inet6 fe80::846d:9dac:e7f:52a4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
ip route :
default via 192.168.2.1 dev wlxe4beed63ad6d proto static metric 600
192.168.2.0/24 dev wlxe4beed63ad6d proto kernel scope link src 192.168.2.50 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
traceroute 8.8.8.8 :
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 zyxel.box (192.168.2.1) 13.491 ms 22.038 ms 25.032 ms
2 p3e9bf58c.dip0.t-ipconnect.de (62.155.245.140) 25.619 ms 25.690 ms 27.039 ms
3 pd900c846.dip0.t-ipconnect.de (217.0.200.70) 33.141 ms 33.337 ms 41.692 ms
4 pd900c846.dip0.t-ipconnect.de (217.0.200.70) 48.071 ms 48.119 ms 48.331 ms
5 80.157.207.46 (80.157.207.46) 50.943 ms 51.167 ms 51.247 ms
6 108.170.247.97 (108.170.247.97) 51.331 ms 74.125.244.97 (74.125.244.97) 29.621 ms 32.176 ms
7 209.85.252.209 (209.85.252.209) 28.730 ms 172.253.75.127 (172.253.75.127) 32.362 ms 172.253.75.93 (172.253.75.93) 34.577 ms
8 dns.google (8.8.8.8) 36.172 ms 35.641 ms 36.628 ms
@01101111:
Hello again and thank you for pointing out that apparmor-matter. It really escaped my attention.
It´s been a while since I read about apparmor. So I´m not really up-to-date.
Yet I remember that the command aa-status yields an overview of the loaded apparmor-profiles.
I have to dig a bit deeper. My reference is https://wiki.ubuntuusers.de/AppArmor/ (yet in German).
Anyway I applied the command and got the following results:
So barrier is covered by apparmor which of course doesn´t mean that it´s blocked automatically.
Besides barrier (on the host) itself says it´s running.
Nevertheless apparmor is blocking something as you pointed out.
mostly i just know the name apparmor. is it possible to list the configuration for the snap.barrier.barrier profiles to see what they might be denying? the fourth log entry also mentions “ping” and “send” after denied which may be part of what is cutting off your discovery. of course that is if avahi is functional give the first few lines.
Thanks for the link. I´ll read it through. Maybe I can come up with something.
In the meantime I looked up the contents of etc/apparmor.d and found there´s no profile for barrier.
I thought that´s weird as aa-status presented me with a result when barrier was running.
A closer look revealed that barrier does have an entry (if it´s running) under :
25 processes have profiles defined.
25 processes are in enforce mode.
but not under:
44 profiles are loaded.
44 profiles are in enforce mode.
Anyway tree /etc/apparmor.d/ | grep barrier shows nothing about barrier, but theoretically it should…
My first thought was to disable the barrier profile. But it seems I can´t because it´s not there.
i realize you are trying to run down how or if it is possible to get apparmor to allow a connection so i am not trying to add more work, but i a thought earlier about the journalctl results you shared previously. were those just from the server? if so, it might be a good idea to check the client as well.
I’m just curious why you’re eschewing Synergy in favour of Barrier?
Is there some feature that Synergy (even the default “free” version in the debian/ubuntu repos) lacks that Barrier provides?
I’ve been using Synergy for 10 years or more - across Linux, Windows and Mac… I love it so much I paid for it, it’s indispensible - but the free version works just as well - e.g. I use the Debian Jessie armhf default repo Synergy 1.4.x client on an NTC CHIP against Synergy Pro 1.11.1 “server” on x86_64… Got an RPi 4 to the far right on a 1080P 27" monitor, then a Ubuntu 20.04 laptop on a 23" monitor, below that another Ubuntu 20.04 laptop, to the right of these, my Ubuntu 20.04 “server” for Synergy (on a Lenovo 32") and then far right an NTC CHIP ARM device running Jessie (and everything works, including clipboard sharing!)…
Synergy’s not perfect, I hate the way it defaults to SSL - I’m not planning on letting the public into my LAN, so I don’t really care that much about security, but it turns it on by default, which breaks connectivity to the server - and when you first install the pro version it nags and nags to register - I wish they’d leave that nagging until you’ve got everything setup…
Can you disable SSL on both client and server with Barrier? I don’t see the point in the extra overhead, unless the ports used are open to the wild internets…
Barrier looks interesting, but, Symless Synergy Pro does the job for me, and I paid for it - but it can be run for free (like I said I’ve been using it 10 years, but only bought it 2 years ago)…
That’s a shame! Last time I used it “free” a tad over 2 years ago, it was still available in most Ubuntu/Debian repos… It’s still available in Debian Jessie I believe - 'cause I was able to install it on my NTC CHIP SBC…
I haven’t tried any of these (I don’t want to break my existing installs of 1.11.1), but I don’t see why they wouldn’t work (almost everytime I install 1.11.x - I have to run “sudo apt install -f” right after to satisfy its dependancies). I don’t see any ARM builds there, but I don’t think you’re doing this on a Pi or anything like that? Note : everything “works” on the Synergy “free” 1.4.x client on my Debian Jessie NTC CHIP to my Synergy Pro 1.11.1 server on x86_64…
i wasn’t trying to compare the kind of networking used. i just meant that by watching journalctl when the connection process wasn’t working i was able to see the errors that neither bluetooth program was sharing with me.