UltraVNC-Repeater

[soso]

Hallo,
hat schon mal jemand versucht ein freetz-Paket für den UltraVNV-Repeater zu erzeugen?
Der C++ Quellcode ist unter GNU-Lizenz frei verfügbar. Das Programm hat keine Ein- oder Ausgaben und ist unter Windows nur 156 KB groß. Ich denke das dieses Programm am sinnvollsten in der FritzBox laufen sollte. Ich wäre auch schon zufrieden wenn es eine Lösung für den Repeater Mode-II gäbe.
Ich habe leider noch nicht genug Ahnung von freetz sonst würde ich selbst mal versuchen ein Packet zu erzeugen.

 

[RalfFriedl]

Hast Du die Stelle im Wiki gesehen, wo die Erstellung eines Packages beschrieben wird?

 

[Whoopie]

Grundsätzlich gilt: Windows != Linux, d.h. nur weil es den Quelltext gibt, heisst es noch lange nicht, dass es sich unter Linux kompilieren lässt.

Es gibt aber einen Linux-Port: http://koti.mbnet.fi/jtko/uvncrepeater/

Im Anhang mal das make/uvncrepeater-Verzeichnis. Damit lässt sich der Repeater unter Freetz kompilieren ("make uvncrepeater-precompiled"). Die ini-Datei nimmt man aus dem source/Ver014-Verzeichnis.
Die Einbindung in make/Config.in überlasse ich Dir.

Beste Grüße,
Whoopie

 

[soso]

Hallo Whoopie,
danke für deine Hinweise. Ich habe die repeater014.zip aus dem Linux-Port runtergeladen. Das Linux-Port enthällt allerdings den Unterordner "eventlistener" mit Java-Class-Files. Damit kann doch freetz warscheinlich garnichts anfangen oder? Was soll ich mit denen machen? Ich weiss nicht ob die wirklich benötigt werden. Außerdem enthällt der Ordner ein Makefile. Soll ich das nehmen oder muss es durch das Makefile am ende dieses HowTo ersetzt werden:
http://trac.freetz.org/wiki/help/ho...e_creation#WiebaueicheineigenesPaketfürFreetz

Gruß soso

 

[RalfFriedl]

Ändere im Titel doch mal VNV auf VNC, sonst findet man diesen Thread nicht, wenn man danach sucht.

 

[soso]

Stimmt vertippt!

 

[soso]

Ich hab mal versucht ein uvncrepeater-Paket zu erzeugen. Leider scheitere ich schon beim Download der richtigen Firmware für meine FritzBox. Die Version die freetz runterladen will ist offensichtlich nicht mehr aktuell (siehe Anhänge). Wie kann ich die Versionsnummer in freetz ändern?

 

[Silent-Tears]

Du bewnutzt bitte als _allererstes_ mal die Suchfunkltion und siehst dir das "Gemecker" üpber unsinnige Screenshots an, wo du doch den Text posten könntest. Wie das Geht: -> Suchfunktion, oder sogar freundlich im Eröffnungsposting von "freetz-linux".

Dazu benutzt du freundlicherweise sogar die falsche freetz-Version, bitte entwederauf den stable-branch updaten oder die aktuellste runterladen.

 

[soso]

Auch freetz-1.1.2 brachte leider die selbe Felermeldung.
Nach stundenlanger Suche bin ich endlich hier gelandet:
http://trac.freetz.org/wiki/FAQ#NosuchfileFRITZ.Box_xxxxxxxxx.aa.bb.cc.image
Ein kleiner Link hätte die Sache erheblich beschleunigt.
Ich habe das aktuelle Firmware-Image unter "Adwanced Options" manuell eingetragen. Leider brachte auch das eine Fehlermeldung (diesmal unter Patches). Erst die Suche nach dem alten Firmware-Image und das manuelle Einfügen unter dl hat das Problem gelöst.

Der freetz Build-Prozess verlief ohne Fehler und ich habe jetzt einen Eintrag "repeater" in den folgenden Verzeichnissen:
./build/modified/filesystem/usr/bin
./source/Ver014
./packages./uvncrepeater-014/root/usr/bin

Ich hoffe das das alles richtig ist.
Leider kann ich das unter VMWare erzeugte repeater-Programm nicht unter VMWare testen. Das liegt vermutlich daran das alle Programme für die MIPS-Architektur der FritzBox kompiliert werden.
Beim Aufruf kommt die Fehlermeldung:
./repeater: 1: Syntax error: "(" unexpected
Es ist aber weit und breit kein "(" im Spiel. Kann ich irgendwie testen ob das Programm auch richtig funktioniert bevor ich das freetz-Image in die Box bringe?

Außerdem muss noch das File uvncrepeater.ini aus einem der Verzeichnisse:
"./make/uvncrepeater/Ver014/" oder "./source/Ver014/"
in das Verzeichniss:
"./build/modified/filesystem/etc/" kopiert werden.
Wie mache ich das am besten automatisiert während des Build-Prozesses?

 

[RalfFriedl]

Nach stundenlanger Suche bin ich endlich hier gelandet

Nach stundenlanger Suche endlich beim FAQ?

Ich habe das aktuelle Firmware-Image unter "Adwanced Options" manuell eingetragen.

Das hast Du also schnell gefunden? Das kann gelegentlich funktionieren, muß aber nicht.

Leider kann ich das unter VMWare erzeugte repeater-Programm nicht unter VMWare testen. Das liegt vermutlich daran das alle Programme für die MIPS-Architektur der FritzBox kompiliert werden.

Richtig vermutet.

Außerdem muss noch das File uvncrepeater.ini ... kopiert werden. Wie mache ich das am besten automatisiert während des Build-Prozesses?

Eine Möglichkeit dafür ist die Datei fwmod_custom.

 

[soso]

Der vnc-Repeater läuft inzwischen unter freetz.
Ich kann mich aber noch nicht verbinden. Im Anhang das Protokoll der Telnet-Sitzung. Ich vermute es liegt daran das der Repeater nach dem Start die Benutzerrechte einschränken will: "dropRootPrivileges". Dazu kann man in der Repeater-Konfigurationsdatei uvncrepeater.ini (Anhang) einen User mit eingeschränkten Benutzerrechten definieren "runasuser = uvncrep". Kennt den freetz überhaupt andere User ausser root? Und wenn ja wie kann ich einen neuen User anlegen der dann auch dauerhaft zur Verfügung steht? Ferner würde ich gerne die uvncrepeater.ini unter Telnet editieren. Ich kann die Datei aber nicht abspeichern obwohl ich als root eingeloggt bin und Schreibrechte vorhanden sind. Warum geht das nicht?

 

[RalfFriedl]

Freetz kann user anlegen und tut das auch in einigen Diensten.
Die Datei steht vermutlich im ROM, und es kommt die Meldung "Read only file system".

 

[soso]

Den User konnte ich anlegen. Die entsprechende Fehlermeldung ist jetzt weg. Ich bekomme aber immer noch die Fehlermeldung:
openConnectionToEventListener(): connectWithTimeout() failed.
Das liegt daran das der EventListener (Java class-Files) noch nicht integriert ist. Gibt es denn überhaupt eine JRE für freetz oder muss der EventListener in C++ umgeschrieben werden? Mir ist nicht ganz klar wieso Teile des Linux-uvncrepeater in Java geschrieben sind. Das Original besteht nur aus c++.
Die uvncrepeater.ini steht in /etc. Wo muss die den stehen damit ich sie editieren kann?

 

[hermann72pb]

Die uvncrepeater.ini steht in /etc. Wo muss die den stehen damit ich sie editieren kann?

Suche hier im Forum bitte nach "mount -o bind". Damit kannst du die bestehende Datei mit einer im RAM (z.B. unter /mod oder /tmp ) temporär (bis zum nächsten reboot) übermounten. Für die ersten Versuche würde es reichen. Danach muss du schauen, wie es bei den anderen FREETZ-Paketen mit den configs und inis gelöst ist. Typischerweise landen sie alle irgendwo unter /mod/... Man muss nur noch dafür sorgen, dass sie nicht nur im RAM (/mod/...) liegen, sondern ab und zu auch im Flash landen (modsave ...). Aber wenn du dir 2-3 passende FREETZ-Pakete anschaust, wirst du schon verstehen wie es gemeint ist.

Zum VNC-Repeater hätte ich auch ein großes Interesse. Wenn ich nachher Zeit finde, würde ich dich evtl. bei der WebIF-Integration unterstützen.
Was bei der Impementierung wichtig wäre:
1. Das Ding sollte als nicht-root laufen. Am besten sollte man dafür einen speziellen User anlegen (z.B. vncuser) und diesem User die Shell und sonstige Privelegien beklauen. Deswegen gehst du schon in die richtige Richtung. Später könnte man sogar so einen User a-la AVM's "ftpuser" per Startscript checken und ggf. automatisch anlegen lassen.
2. C wäre schon wichtig. Zwar gibt es Bestrebungen Java auf der Box laufen zu lassen, aber meiner Meinung nach wäre es eine Nummer zu gross, wenn es auf Java aufsetzen würde. Soweit ich es in Erinnerung habe, braucht VNC Java, wenn man VNC über HTTP und Browser macht. Vielleicht kann man zunächst darauf verzichten, wenn man diese Browserfunktionalität nicht benutzt.
3. Wichtig wäre es im nächsten Schritt die SSL-Verschlüsselung hinzubekommen. Ich kenne es zwar von der Idee und der Struktur nicht, ob es notwendig ist, dass der Repeater die Verschlüsselung macht, oder ob es den Servern überlassen wird. Dadurch, dass die SSL-Problematik bei uns nun sauber gelöst ist, wäre es denkbar dafür stunnel und Co. zu verwenden oder direkt OpenSSL-Libs anzusprechen. An sich dürfte es laufen, denn im Prinzip nutze ich jetzt schon VNC über dropbear-Tunnel und es funktioniert recht gut. Früher hatte auch VNC über OpenVPN funktioniert. Man darf nur bei VNC die Qualität/Auflösung nicht zu hoch treiben, sonst hat man verloren.

MfG

 

[RalfFriedl]

Mir ist nicht ganz klar wieso Teile des Linux-uvncrepeater in Java geschrieben sind.

Ernsthaft? Ich kann mir keinen guten Grund dafür vorstellen, ein relativ systemnahes Problem in Java zu lösen, erst recht nicht teilweise. (Soll nicht heißen, daß Deine Beobachtung falsch ist, nur nicht nachvollziehbar.)

2. C wäre schon wichtig. ... . Soweit ich es in Erinnerung habe, braucht VNC Java, wenn man VNC über HTTP und Browser macht.

Wie schon oben angedeutet, ist eine Java VM für so eine Aufgabe absoluter Overkill.
VNC über Browser braucht Java, aber auf dem Browser auf dem Client-PC. Auf dem VNC-Server ist das Java-Programm nur eine Datei, die an den Client ausgeliefert wird, und falls der Repeater überhaupt die HTTP-Verbindung unterstützt, muß er sie auch nur transparent weiterleiten, als kein Bedarf an einer Java VM beim Repeater oder beim Server.

3. Wichtig wäre es im nächsten Schritt die SSL-Verschlüsselung hinzubekommen.

Soweit ich weiß, gibt es keinen Standard für Verschlüsselung bei VNC, aber evtl. Erweiterungen mit Verschlüsselung. Die Verschlüsselung sollte besser im Server und im Client erfolgen, die normalerweise leistungsfähiger sind als die Box.

 

[soso]

Vieleicht kann sich ja mal jemand den Quellcode aus dem Link von Whoopie anschauen. Die Fehlermeldung bezieht sich auf den EventListener und der ist in Java geschrieben und befindet sich in einem Unterverzeichniss des C++ Quellcodes. Möglicherweise wird der nicht substantiell gebraucht und man kann den entsprechenden Aufrug im C++ Quellcode entfernen.
Eine Verschlüsselung gibt es auch im original VNC-Repeater nicht. Es werden nur die Datenpakete an den entsprechenden Empfänger weitergereicht. Verschlüsselt und entschlüsselt wird nur im Server und Viewer.

 

[soso]

Ich bin einen Schritt weiter!
Der Java-EventListener wird nur zu informativen Zwecken benötigt und kann deaktiviert werden. Ich habe einen neuen User "uvnvrep" angelegt und anschliessend der Repeater gestartet (Protokoll im Anhang). Es sieht so aus als ob der in einer Schleife auf eingehende Verbindungen wartet. Beim Versuch einen VNC-Server und einen VNC-Client am Repeater anzumelden tut sich aber nichts. Muss man bei der FritzBox erst noch die Ports eingangsseitig freigeben?

 

[doc456]

Hallo,

eigentlich wird für den Server der Port 5900/TCP und den Viewer 5800/TCP benötigt, ergo solltest du beide Ports öffnen.

Ich sehe gerade in deinem Log, dass der Server auf 5500 und der Viewer auf 5901 lauscht...

EDIT: Wie sieht denn die Performance aus, wenn der im Loop läuft?

 

[hermann72pb]

@doc456: 5800 wird typischerweise bei VNC für die Java-Browser-Unterstützung benutzt. Die auf den PCs installierten VNC-Server lauschen normalerweise auf dem Port 5900. Es könnte sein, dass es im Falle von Linux-Rechner der Port 5901 ist, denn ich kann mich dunkel erinnern, dass wenn man sich mit Linux-VNC-Sever verbinden wollte, dass man :1 dahinter schreiben sollte, was in "VNC-Sprache" eine Portnummer größer als default heißt, also 5901.
Daher könnte es sein, dass der Repeater per default (ohne :1 dahinter) nicht den Port 5900 absucht, sondern 5900.
Der Serverport 5500 würde der Port sein, den du adressieren soltest, wenn du die Verbindung über den Repeater herstellst. Also, bei Proxy/Repeater unter UltraVNC-Klient solltest du vermutlich fritzbox:5500 eintragen (oder fritzbox::5500), wenn ich das richtig überblicke.
Den ersten internen test kannst du machen, ohne großartig Firewall freizugeben. Wenn alles läuft gibst du den Port 5500 (oder was auch immer) nach draußen frei.

Mir gefällt dennoch die Lösung nicht besonders es nach draußen frei zu geben. Deswegen hatte ich auch nach Verschlüsselung gefragt. Ich hatte den Repeater noch nie benutzt und kenne die Philosophie gar nicht. Ist es richtig, dass der Repeater selbst auch keine Benutzerkontrolle beinhaltet? Machen wir damit nicht ein großes Tor nach draußen auf? Denn wenn es weder Verschlüsselung noch Benutzerverwaltung beim Repeater existiert, kann ich rein theoretisch über diesen Repeater jeden beliebigen Rechner an fast jedem beliebigen Port hinter der Firewall ansprechen? Ist das wirklich gut?

MfG

 

[soso]

Der Repeater lauscht standardmäßig auf die Ports 5500 (Server) und 5901 (Viewer). Ich benötige eigentlich nur den Mode II. Dabei muss weder der Viewer noch der Server irgendwelche Ports forwarden. Das ist von Vorteil wenn ich Unterwegs bin und über einen WLAN-Hotspot oder UMTS online gehe. Da habe ich nämlich keinen Einfluss auf das Port-Forwarding. Nur beim Repeater müssen die beiden Ports offen sein und den hab ich unter Kontrolle da der bei mir zuhause steht. Wenn der Repeater auf einem Rechner hinter einer FBF läuft muss ich diese beiden Ports von der FBF zum Rechner forwarden. Aber was muss ich machen wenn der Repeater in der FBF selbst läuft?

@hermann72pb
Der Repeater hat mit der Verschlüsselung nichts zu tun. Die findet nur im Server und im Viewer statt wenn man das will.

@doc456
Was meinst du mit Performance? Wie kann ich die messen? Der Repeater macht keine weiteren Ausgaben solange keine weiteren Ereignisse stattfinden (z. B. die Anmeldung von Server oder Viewer).