Barrier (OpenSource KVM Switch Software)
Inhaltsverzeichnis
Allgemeines
Auf meinen Schreibtisch hat gerade der dritte Rechner (1xLINUX, 2xWIN10) Platz genommen. Der LINUX-PC (Doppelmonitorsystem 28" 4K) und der WIN-PC (32" 4K) benötigten bisher jeweils ein KM-Set. Der zweite WIN-PC ist ein 20 Zoll Tablet-PC, der gluecklicherweise auch ohne Tastatur/Maus-Kombi auskommt.
Problem
Die Anzahl von KeyboardMouseSets (KMs) ist zu grosz. Es passiert mir realiv haeufig, dass ich auf dem falschen Keyboard tippe.
Lösungen
KVM-Switches waeren hier denkbar. Da ich aber die Video-Umschalte nicht benoetige und zudem bisher kein befriedigendes KVM kenne, geht die Suche hier in Richtung Softwareloesung. Da meine bisherigen KVMs gerade beim Booten und beim Umschalten auf einen ausgeschalteten PC Probleme hatten, bin ich mal auf das Verhalten der Softwareloesung gespannt.
Es gibt zwar auch USB-Switcher, also USB-Hubs, die gleichzeitig an >=2 PC angeschlossen bleiben koennen. Die Probleme mit Verbindungsabbruechen scheinen aber aehnlich denen bei den KVMs zu sein.
Wen's trotzdem interessiert kann ja mal nach folgendem oder aehnlichem suchen:
UGREEN USB 2.0 KVM 4 Ports HUB für 2 PCs 2 In 4 Out Umschalter mit 2 USB 2.0 Kabel für Drucker, Scanner, Tastaturen, USB Sticks, Externe Festplatten, Mäusen, Headsets usw Schwarz
Es hat nicht sehr lange gedauert bis ich im Netz auf die Software "Synergy 1" gestoszen bin. Macht spontan einen guten Eindruck. Leider gibt es keine Demo-Version, aber ein Geld-zurueck-Versprechen. Bevor ich also zuschlage noch ein bisschen im Netz weitergesucht.
Folgende Infos ließen das Bild klarer werden.
- Synergy 1 Version Feature List
- Beschreibung des Einsatzes von Synergy 1
- Überblick über viele Alternativen
Da alle Produkte, die eine RemoteDesktop-Verbindung aufbauen, für mein Problem über das Ziel hinausschießen und alle Produkte ohne LINUX-Support ausscheiden, blieb tatsächlich am Ende scheinbar nur Synergy 1 übrig. Bevor ich aber die 39$ für die Pro Version ausgegeben hatte, bin ich per Zufall noch ueber einen Hinweis auf ein OpenSource Projekt namens Barrier gestolpert.
Also zu GitHub und mal nachgelesen. Das ist doch tatsaechlich ein Synergy-Fork und bietet sogar SSL gleich mit an.
LINUX-PC: Eine Suche im Repository von OpenSuse ergab sofort einen Treffer. Installation->Start->ConfigServer->Fertig
WINDOWS-PC: Binaries von GitHub. Installation->Start->ConfigClient->Fertig
Noch schnell zur ersten Verbindungsaufnahme (siehe unten) die Firewall abgeschaltet und siehe da, es klappt wie gewünscht. Eureka, ich bin begeistert!!!
Datentransfer
TODO
Problem(e)
20210529
Nach einem Update des LINUX-PC von OpenSuSE 15.2 auf 15.3 musste ich erst einmal das Barrier-Paket nachinstallieren. Nach dem Start des Barrier-Servers war zwar meine Config noch da, aber der Client (WIN-PC) konnte keine Verbindung aufbauen. Der Aufruf des Log (F2) auf dem WIN-PC bestaetigte das Verhalten.
[2021-05-29T10:41:24] NOTE: connecting to '192.168.178.XX': 192.168.178.XX:24800 [2021-05-29T10:41:39] WARNING: failed to connect to server: Timed out
Da ich am WIN-PC nichts geaendert hatte lag die Vermutung nahe, dass der Fehler auf der Linux-Seite zu suchen ist. Die Umstellung des Protokollierungsumfangs in den Einstellungen (Barrier->Change Settings F4) von Barrier von 'Warnung' auf 'Debug2' hat sich als hiflreich erwiesen.
- Mit iptables die Firewallregeln ueberprueft -> Keine Regeln aktiv
- ping von WIN-PC auf LINUX-PC -> ok
- tcpdump auf LINUX-PC -> Pakete kommen auf Port 24800 an
- ss -lptn auf LINUX-PC -> user barriers lauscht auf Port 24800 ok
- ps aux | grep <pid> auf LINUX-PC -> barrier ok
- telnet und cnf auf WIN-PC auf Server Port 24800 -> ebenfalls Timeout
- barrier gestoppt und Port 24800 mit nc -lk -p 24800 gebunden
- telnet localhost port 24800 -> ok
- telnet von anderem LINUX-PC auf port 24800 -> geht nicht!!!!!!!!
An der Stelle musste ich erst mal durchatmen. Internetkommunikation und ping untereinander ging alles, nur die eingehende Kommunikation auf meinen Arbeitsplatzrechner ging nach dem Update, trotz ausgeschalteter Firewall nicht. Dann habe ich allerdings mit systemctl status firewalld gesehen, dass der Firewall-Daemon gar nicht laeuft. Iptables hatte mir allerdings klaglos eine leere Regeltabelle gezeigt.
Mit
systemctl enable firewalld
und mit
systemctl start firewalld
die Firewall gestartet.
Jetzt aenderte sich die Log-Status-Meldung auf dem WIN-PC wie folgt.
[2021-05-29T10:41:40] NOTE: connecting to '192.168.178.XX': 192.168.178.XX:24800 [2021-05-29T10:41:42] WARNING: failed to connect to server: Connection was refused
Nachdem nochmal alle Regeln geloescht wurden, war die Verbindung sofort wieder da.:-)
Die Vermutung, dass es mit dem Forwarding zu tun hat, bestaetigte sich nicht.
sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0
oder
cat /proc/sys/net/ipv4/ip_forward 0
Bis heute weisz ich nicht, welche Aenderung sich an meiner Netzwerk(karten)einstellung durch den nicht eingeschalteten Firewall-Daemon ergeben hat.
20211026
Nach einem Neustart des Linux-PC ist mir aufgefallen, dass es bei der Kontaktaufnahme hakt.
- iptabels -L -> leer
- systemctl status firewalld -> laeuft
Firewall-Daemon gestoppt -> Barrier laeuft sofort
Auszerdem lief der barrier-Server auf einmal doppelt. Das konnte ich mir spontan nur dadurch erklaeren, dass ich barrier im KDE-Autostart (Arbeitsflächen-Sitzung Systemeinstellungen) angelegt hatte, als auch die Option gewaehlt habe "Bei der Anmeldung - Vorherige Sitzung wiederherstellen". Ich habe barrier im Autostart mal deaktiviert. Mal sehen ob's hilft.
Ich vermute dahinter ein Phaenomen, dass iptables, was ja nach dem Wechsel zu nftables jetzt nur noch ein Link auf xtables-legacy-multi ist, beim Aufruf mir nicht die ganze Wahrheit offenbart. Ich glaube es ist an der Zeit, dass ich mich von iptables komplett verabschiede. Was openSuSE da mit firewall-cmd treibt muss ich noch rausfinden. (TODO Vergleich iptables, nftables, firewalld)
Nachdem die barrier-Clients Verbindung aufgenommen haben, bleibt die Verbindung auch nach dem wieder einschalten der Firewall bestehen.
20230217
Nach der Neuinstallation des Linux Rechners (openSuSE 15.4) gings erst mal gar nichts mehr. Die in 15.4 bereitgestellte Version ist 2.4.0. Also dann auch unter Win10 die neue Version installiert. Obwohl in der neuen Linux-Firewall der Port 24800 zur Kontaktaufnahme offen war reagierte der Barrier-Server auf dem Linux-Rechner nicht. Die Pakete vom Windows-Client kamen an wurden aber vom Barrier-Server nicht beantwortet. SSH war ausgeschaltet.
Im Debug2-Log des Server sah ich folgendes.
[2023-02-20T06:02:56] DEBUG2: event: MotionNotify 0,1084 [2023-02-20T06:02:56] DEBUG2: find neighbor on left of "SERVER" [2023-02-20T06:02:56] DEBUG2: ignored "CLIENT" on left of "SERVER" [2023-02-20T06:02:56] DEBUG2: no neighbor on left of "CLIENT" [2023-02-20T06:02:56] DEBUG1: try to leave "SERVER" on left [2023-02-20T06:02:56] DEBUG1: no neighbor left
Bis auf die Zeile 'no neighbor on left of "CLIENT"' soweit alles klar. Was er hier links vom Client sucht ist mir nicht klar. Es waere denkbar, dass in einer >3 Kette der mittlere "abgeschaltete" Client uebersprungen wird.
Der Start des Servers ergab folgenden Log.
[2023-02-19T18:13:42] DEBUG: screen shape: 0,0 7680x2160 (xinerama) [2023-02-19T18:13:42] DEBUG: window is 0x04a00004 [2023-02-19T18:13:42] DEBUG: adopting new buffer [2023-02-19T18:13:42] DEBUG: opened display [2023-02-19T18:13:42] DEBUG1: registered event type error as 4 [2023-02-19T18:13:42] DEBUG1: registered event type suspend as 5 [2023-02-19T18:13:42] DEBUG1: registered event type resume as 6 [2023-02-19T18:13:42] DEBUG1: creating primary screen [2023-02-19T18:13:42] DEBUG1: registered event type connecting as 7 [2023-02-19T18:13:42] DEBUG1: binding listen socket [2023-02-19T18:13:42] DEBUG1: listening for clients [2023-02-19T18:13:42] DEBUG1: registered event type connected as 8 [2023-02-19T18:13:42] DEBUG1: registered event type keyDown as 9 [2023-02-19T18:13:42] DEBUG1: registered event type keyUp as 10 [2023-02-19T18:13:42] DEBUG1: registered event type keyRepeat as 11 [2023-02-19T18:13:42] DEBUG1: registered event type buttonDown as 12 [2023-02-19T18:13:42] DEBUG1: registered event type buttonUp as 13 [2023-02-19T18:13:42] DEBUG1: registered event type motionOnPrimary as 14 [2023-02-19T18:13:42] DEBUG1: registered event type motionOnSecondary as 15 [2023-02-19T18:13:42] DEBUG1: registered event type wheel as 16 [2023-02-19T18:13:42] DEBUG1: registered event type screensaverActivated as 17 [2023-02-19T18:13:42] DEBUG1: registered event type screensaverDeactivated as 18 [2023-02-19T18:13:42] DEBUG1: registered event type switchToScreen as 19 [2023-02-19T18:13:42] DEBUG1: registered event type toggleScreen as 20 [2023-02-19T18:13:42] DEBUG1: registered event type switchInDirection as 21 [2023-02-19T18:13:42] DEBUG1: registered event type keyboardBroadcast as 22 [2023-02-19T18:13:42] DEBUG1: registered event type lockCursorToScreen as 23 [2023-02-19T18:13:42] DEBUG1: registered event type fakeInputBegin as 24 [2023-02-19T18:13:42] DEBUG1: registered event type fakeInputEnd as 25 [2023-02-19T18:13:42] DEBUG1: registered event type shapeChanged as 26 [2023-02-19T18:13:42] DEBUG1: registered event type clipboardGrabbed as 27 [2023-02-19T18:13:42] DEBUG1: registered event type clipboardChanged as 28 [2023-02-19T18:13:42] DEBUG1: half-duplex caps-lock off [2023-02-19T18:13:42] DEBUG1: half-duplex num-lock off [2023-02-19T18:13:42] DEBUG1: half-duplex scroll-lock off [2023-02-19T18:13:42] DEBUG1: screen saver synchronization on [2023-02-19T18:13:42] DEBUG1: Preserve Focus = false [2023-02-19T18:13:42] DEBUG1: XTest is Xinerama unaware false [2023-02-19T18:13:42] DEBUG1: XKB mapping
Nach der Initialisierung des Servers und einem 'waiting for clients' dann die Kontaktaufnahme.
[2023-02-19T19:30:56] DEBUG: Opening new socket: C6F38570 [2023-02-19T19:30:56] NOTE: accepted client connection [2023-02-19T19:30:56] DEBUG1: saying hello [2023-02-19T19:30:56] DEBUG2: writef(Barrier%2i%2i) [2023-02-19T19:30:56] DEBUG2: wrote 11 bytes [2023-02-19T19:30:56] DEBUG1: parsing hello reply [2023-02-19T19:30:56] DEBUG2: readf(Barrier%2i%2i%s) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 1 (0x1) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 6 (0x6) [2023-02-19T19:30:56] DEBUG2: readf: read 6 byte string [2023-02-19T19:30:56] DEBUG1: querying client "CLIENT" info [2023-02-19T19:30:56] DEBUG2: writef(QINF) [2023-02-19T19:30:56] DEBUG2: wrote 4 bytes [2023-02-19T19:30:56] DEBUG1: created proxy for client "CLIENT" version 1.6 [2023-02-19T19:30:56] DEBUG2: msg from "CLIENT": DINF [2023-02-19T19:30:56] DEBUG2: readf(%2i%2i%2i%2i%2i%2i%2i) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 0 (0x0) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 0 (0x0) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 2560 (0xa00) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 1440 (0x5a0) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 0 (0x0) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 0 (0x0) [2023-02-19T19:30:56] DEBUG2: readf: read 2 byte integer: 0 (0x0) [2023-02-19T19:30:56] DEBUG: received client "CLIENT" info shape=0,0 2560x1440 at 0,0 [2023-02-19T19:30:56] DEBUG1: send info ack to "CLIENT" [2023-02-19T19:30:56] DEBUG2: writef(CIAK) [2023-02-19T19:30:56] DEBUG2: wrote 4 bytes [2023-02-19T19:30:56] NOTE: client "CLIENT" has connected [2023-02-19T19:30:56] DEBUG1: send reset options to "CLIENT" [2023-02-19T19:30:56] DEBUG2: writef(CROP) [2023-02-19T19:30:56] DEBUG2: wrote 4 bytes [2023-02-19T19:30:56] DEBUG1: send set options to "CLIENT" size=26 [2023-02-19T19:30:56] DEBUG2: writef(DSOP%4I) [2023-02-19T19:30:56] DEBUG2: wrote 112 bytes
Ein weiterer Grund fuer eine verlorene Verbindung ist gegeben , sobald der Windows-PC eine "Admin-Anfrage", z.B. beim Installieren einer Software stellt. Dabei springt die Maus auf den Server zurueck, es wird eine neue Verbindung mit einem neuem Port geoeffnet und erst dann kann man erneut auf den Windows-PC zugreifen. Dieser Umstand wird durch die Firewall nicht beguenstigt.
Die automatische Aktualisierung der Kommentare aktivieren.