Fritzbox als rustdesk-server?

[f-user]

Hier eine Liste der aktuell (28.11.2024) von Freetz unterstützten Fritzboxen:




Hier eine Liste, die u.a. auch die 7690 und 5690 Pro enthält, welche aber noch nicht im Menü angezeigt werden:

freetz-ng/docs/FIRMWARES.md at master · Freetz-NG/freetz-ng

Freetz-NG firmware modification for AVM devices like FRITZ!Box - Freetz-NG/freetz-ng

github.com

Bild(er) als Vorschaubild(er) (siehe https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ ) eingebunden by stoney

 

[NanoBot]

Zur Information:

Ich habe heute im Rahmen eines Tarifwechsel eine 7690 bekommen. Und dort laufen die gleichen binaries wie auf der 7530, also arm7. Den Krampf mit dem USB-Stick konnte ich mir natürlich sparen, weil diese Box viel mehr RAM und Flashrom hat als die 7530. Und starten kann ich den rustdesk-server jetzt problemlos über rc.custom anstelle von autorun.sh, weil nicht erst auf die Erkennung des USB-Sticks gewartet werden muß. Die Methode mit dem "mount --rebind" unter /opt habe ich allerdings beibehalten, auch wenn dies nicht wirklich notwendig wäre.

Die Box ist allerdings noch nicht im "echten" Betrieb, so daß ich erst in 1-2 Tagen sagen kann, ob es auch wirklich problemlos funktioniert.

 

[NDiIPP]

Und dort laufen die gleichen binaries wie auf der 7530, also arm7.

Jein. Die 7690 nutzt m.W.n. einen (neueren) ARM Cortex A53, also einen ARMv8-A (AArch64). Die 7530 dagegen einen älteren ARMv7 (AArch32). Ein Cortex A53 ist zwar auch zu ARMv7-A (AArch32) Binaries kompatibel aber falls verfügbar kann (bzw. sollte) man auf einer 7690 vielleicht gleich 64-Bit Binaries für ARMv8 AArch64 nutzen.

Also beim rustdesk-Server auf einer 7690 (oder auch 5690 Pro, 5590, 4060) vermutlich besser gleich auf "rustdesk-server-linux-arm64v8" zurückgreifen anstatt auf "rustdesk-server-linux-armv7".

 

[NanoBot]

Werde ich mal ausprobieren. Ich hatte auf die Schnelle nur mal ein "cat /proc/cpuinfo" gemacht, und dort wurden die Kerne alle als ARMv7 bzw. v7l angezeigt. Und da ich die Arm7 binaries von der 7530 ja sowieso schon hatte habe ich diese genutzt und es funktionierte soweit wie es soll. Möglicherweise wären die ARMv8 besser, wenn viele Verbindungen zu gleicher Zeit über den Relayserver laufen würden, aber das kommt in der Praxis bei mir nicht vor.

Nachtrag:
Der Rustdesk-Server läuft auf der 7690 im Realbetrieb bisher ohne Probleme.

Zweiter Nachtrag:
Bis jetzt ist es auf der 7690 nicht mehr passiert, daß sich einer der beiden Prozesse des Rustdesk-Servers spontan beendet hätte. Vermutlich liegt dieses Verhalten also daran, daß die 7530 nur 256MB Ram hat, während die 7690 1024MB Ram hat. Somit kann man auch vermuten, daß der Rustdesk-Server auf einer 7530ax, welche ja 512MB Ram besitzt, besser laufen würde als auf der bisher von mir genutzen 7530 ohne ax. Die Notwendigkeit der Nutzung eines USB-Sticks wäre dagegen auch bei einer 7530ax weiter gegeben, da die Größe der Flashspeichers bei 7530 und 7530ax identisch und somit zu gering ist.

Da die arm7 binaries bisher problemlos laufen, habe ich bisher nicht probiert, die arm8 binaries stattdessen zu nutzen.

 

[f-user]

Was hat die 7690 eigentlich für eine Leistungsaufnahme "in Ruhe", bei ausgeschaltetem WLAN, an DSL? Die Werte, die mir bisher so untergekommen sind (12-13 W, "im Durchschnitt"), kommen mir etwas hoch vor für's "Nichtstun" im Vergleich zu 7490 und 7590 und für einen arm-Prozessor.

 

[NDiIPP]

Die Werte, die mir bisher so untergekommen sind (12-13 W, "im Durchschnitt"), kommen mir etwas hoch vor für's "Nichtstun" im Vergleich zu 7490 und 7590 und für einen arm-Prozessor.

Na immerhin weniger als die 14-16W der WiFi-6 Vorgängerin 7590 AX (mit zudem "schwacher" MIPS32-CPU).

 

[NanoBot]

Ein Hinweis für Leute, welche auf ihrer Box einen Rustdesk-Server einrichten wollen oder aus einem anderen Grunde Ports direkt auf die interne IP der Fritz!Box weiterleiten wollen:

Es gibt ein neues Paket für freetz-ng, welches genau dies jetzt mit Hilfe des Befehls pcplisten per GUI ermöglicht:
https://freetz-ng.github.io/freetz-ng/make/avm-rules.html

Die von mir beschriebene hier https://www.ip-phone-forum.de/threads/fritzbox-als-rustdesk-server.318700/post-2551824 beschriebene Methode, die benötigten Ports mit Hilfe des crond und eines Scripts weiter zu leiten sollte somit obsolet sein, weil das neue Paket ein GUI besitzt und somit einfacher zu konfigurieren ist.

 

[f-user]

Danke für den Hinweis!

Habe es gleich einmal ausprobiert, funktioniert leider bei mir nicht. Zumindest funktionieren hbbr / hbbs damit nicht. Ev. weil sie die von AVM-rules fest vorgegebene IP-Adresse (169.254.1.1) nicht nutzen dürfen oder können.

Bei hbbr kann man keine IP-Adresse vorgeben, also könnte es allein schon daran liegen. Wenn ich die IP-Adresse für hbbs von der in der normalen Fritzbox-Weboberfläche eingestellten IP-Adresse auf 169.254.1.1 umstelle geht jedenfalls (auch) nichts.

Schade.

Es sei denn, ich habe etwas falsch gemacht / übersehen...

 

[NanoBot]

Ich habe noch kein Image mit diesem Paket getestet. Wird denn auf der Konfigurationsseite des Paketes avm_rules angezeigt, daß Ports geöffnet sind ?


Ansonsten kam mir die feste Vorgabe 169.254.1.1 erstmal komisch vor. Aber wenn man auf der FB diesen Befehl nutzt

root@fritz:/ftp/opt/rustdesk# ifconfig | grep lan
lan       Link encap:Ethernet  HWaddr 60:B5:8D:FB:0C:0B
lan:0     Link encap:Ethernet  HWaddr 60:B5:8D:FB:0C:0B

sieht man, daß die FB für die gleiche Schnitstelle zwei IP nutzt, nämlich einerseits die vom User vergebene IP, welche von Fall zu Fall verschiedenen ist und andererseits die 169.254.1.1, welche immer gleich ist. Daher macht die Nutzung dieser zweiten IP durchaus Sinn.

Ich werde sobald ich Zeit dafür habe mal ein Image mit diesem neuen Paket testen und dann Bescheid sagen

 

[f-user]

Beim Stöbern in der FOS-Weboberfläche habe ich unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> Tabelle für statische Routen -> IP4-Routen gefunden und versucht darüber die beiden IP-Adressen zu "verlinken". Aber ev. in der falschen Richtung. Und wenn die Fritzbox das von Haus aus schon machen sollte, wäre es sowieso überflüssig...

Danke jedenfalls für die zusätzlichen Informationen!

 

[PeterPawn]

wäre es sowieso überflüssig

Das dürfte der Fall sein - aber sind die Supportdaten und/oder der Shell-Zugriff nicht aussagekräftig genug?

Wenn sich ein Daemon nicht automatisch an alle vorhandenen Interfaces binden sollte (was je nach Implementierung ja der Fall sein kann), dann kann man ihm i.d.R. entweder die Adresse(n) vorgeben (s.z.B. sshd) oder man kann auch hier: https://github.com/Freetz-NG/freetz...kgs/avm-rules/files/root/usr/bin/avm-rules#L6 einfach die verwendete lokale IP-Adresse ändern (gilt dann natürlich für alles, was man damit verwaltet) - ja, mit geringstem Aufwand läßt sich die lokale IP-Adresse sogar dynamisch ermitteln (und dann kann man die von der lan-Bridge nehmen) und sogar unterschiedliche Adressen lassen sich verwenden, wenn man die auch noch als Parameter verfügbar macht.

 

[f-user]

Danke @PeterPawn für deine Ideen und Denkanstöße!

sind die Supportdaten und/oder der Shell-Zugriff nicht aussagekräftig genug?

Wenn man damit weitgehend vertraut ist bzw. die richtigen Fragen per Befehl stellen kann - sicherlich.
Allerdings habe Supportdaten vermutlich erst ein einziges Mal vor vielen Jahren erstellen lassen. Und von der Existenz von Befehlen, die ich in meinem Alltag nicht brauche, erfahre ich nur im Einzelfall und "nutze" sie dann per copy&paste...

Am einfachsten (und meiner Natur am nächsten) scheint mir die Editierung der avm-rules-Datei zu sein, weshalb ich diese sicherlich ausprobieren werde. Auch wenn sie wohl die uneleganteste und verpönteste Variante sein dürfte...

Jedenfalls ist mein Forscherdrang wieder erweckt und eine zweite Runde zu diesem Thema steht an.

Nachtrag:

Ich habe allerdings beim letzten Test nmap bemüht, um zu sehen, ob die gewünschten ports per dyndns-Adresse verfügbar sind. Da aber der rustdesk-Client nichts "gesehen" hat, habe ich mir nicht einmal gemerkt wie das Ergebnis ausfiel, da ich nmap zum ersten Mal benutzt habe und verschiedene Befehlsvarianten ausprobiert habe. Muß ich wohl noch einmal eingehender testen.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Erste Ergebnisse:

Das Editieren der IP-Adresse in /git/freetz-ng/make/pkgs/avm-rules/files/root/usr/bin/avm-rules zur selbst-eingestellten der FB führt wenig überraschend zum Erfolg.

Ein erneuter Test mit nmap hat mich erinnert, daß dieser nicht hilfreich ist, da er für beide IP-Adressen in avm-rules die Ports als offen erkennt.

Verwendeter Befehl:
nmap -Pn -p 21116 [dyndns-Adresse]


Das bedeutet das wohl (wie schon nach meinem ersten Test vermutet), daß die Binärdateien von rustdesk-server einfach nicht auf der 169.254.1.1 "senden", d.h. die 169.254.1.1 und die selbst-eingestellte IP-Adresse nicht verknüpft werden, jedenfalls nicht so, daß rustdesk-server damit etwas anfangen kann. Da man auch nur einer der beiden Binärdateien eine IP-Adresse auf den Weg geben kann, wird es wohl auch nicht möglich sein, auf diesen Wege eine Verwendung der 169.254.1.1 durch die Binärdateien zu erzwingen - falls das aus sicherheitstechnischer Sicht überhaupt eine gute Idee wäre.

Im Übrigen werden bei avm-rules bei der Verwendung des eingangs erwähnten "Hacks" noch 2 weitere ports (5060 und 9) als geöffnet angezeigt, die nicht in den Einstellungen eingegeben wurden, also anderswo im System hinterlegt sind, vermutlich von AVM selbst. Diese Port werden wohl exklusiv für die "andere" IP-Adresse, die standardmäßig die 192.168.178.1 wäre, geöffnet, aber nicht für die 169.254.1.1. Interessanterweise wird Port 5060 von nmap als geöffnet erkannt, Port 9 aber als "filtered".

Für den erfahrenen Netzwerker vermutlich logische und erwartbare Resultate, für mich sicher nicht...

 

[NanoBot]

Ja, das sieht dann wirklich danach aus, als ob der Rustdesk-Server nur auf der IP-Adresse der Schnittstelle "lan", aber weder auf der Schnitstelle "lan:0" (169.254.1.1) noch auf lo (127.0.0.1) lauscht. Daher muß pcplisten zwingend auf die "offizielle" interne IP der FB weiterleiten. Den Workarround, nämlich die IP-Adresse manuell im Sourcefile zu verändern, hat Peter Pawn ja genannt. Vergiss aber nicht vor dem nächsten "git pull" von freetz-ng die Originaldatei wieder herzustellen, sonst klappt das nicht.

Ich werde auf github mal einen Kommentar schreiben und fda77 vorschlagen, die Ziel-Adresse der Weiterleitung im GUI des Paketes konfigurierbar zu machen, denn dies wäre die einfachste Lösung des Problems.

Noch so zur Info: Port 5060 ist der Standardport für SIP und muß daher offen sein, und Port 9 wird für Wakeup-on-Lan verwendet. Und außerdem ist vor vier Tagen eine neue Version des Rustdesk-Servers released worden: https://github.com/rustdesk/rustdesk-server/releases

 

[f-user]

Danke für die Bestätigung.

Es wäre natürlich praktisch, wenn das avm-rules Skript einfach die eingestellte IP (von lan) auslesen und verwenden würde.

Die letzten beiden Version von rustdesk-server scheinen mir keine relevanten Änderungen zu enthalten, sind aber größer, daher bleibe ich auf 1.1.12. Ich hatte schon diverse Images mit offiziellen und selbst-kompilierten Binärdateien für 1.1.12 und 1.1.13 gemacht und festgestellt, daß die offiziellen von 1.1.12 am wenigsten Speicherplatz auf der 7530 brauchen, obwohl die selbst-kompilierten auf dem Rechner deutlich kleiner sind... Dürfte eine Komprimierungssache x86 vs arm sein, da der Freetz-Erstellungsprozess die Binärdateien wohl anders komprimiert.

 

[NanoBot]

Also zumindenstens bei der arm7 Version sind die binaries der 1.1.14 gegenüber der Version die ich bisher hatte wesentlich kleiner geworden:

root@fritz:/opt/rustdesk# ls -l hbbr* hbbs* rustdesk-utils*
-rwxrw-rw-    1 root     root       2659892 Jan 25 14:01 hbbr
-rwxrw-rw-    1 root     root       8617416 Oct  7 10:38 hbbr_old
-rwxrw-rw-    1 root     root       6977184 Jan 25 14:01 hbbs
-rwxrw-rw-    1 root     root      11914168 Oct  7 10:38 hbbs_old
-rwxrw-rw-    1 root     root        492860 Jan 25 14:01 rustdesk-utils
-rwxrw-rw-    1 root     root       4752380 Oct  7 10:38 rustdesk-utils_old

Und für das Paket avm-rules gibt es einen Patch zum testen, was ich auf die Schnelle aber nicht selber machen kann. Guck mal hier:
https://github.com/Freetz-NG/freetz-ng/discussions/1096

Falls du das testen willst, solltest du vorher natürlich ein "git pull" machen um auf dem aktuellen Stand zu sein.

 

[f-user]

Ich habe einfach kurz die Änderungen manuell vorgenommen.

Wie es scheint, funktioniert der Patch nicht nur, sondern enthält beide Varianten*, ein Feld zum Eintragen der IP, zum anderen wird aber wohl die lan-IP ausgelesen und übernommen. Beim ersten Start stand nämlich die 169.254.1.1 im Feld drin, aber im "Überwachungsfeld", das die geöffneten Ports anzeigt, wird die lan-IP angezeigt. Beim Screenshot unten war die Box noch nicht online, daher fehlt letzteres aber das IP-Feld als Haupt-Änderung ist ja sichtbar.

* Dem Patch kann ich das zwar nicht entnehmen, aber von der resultierenden Funktion her scheint es so zu sein.

 

[PeterPawn]

zum anderen wird aber wohl die lan-IP ausgelesen und übernommen

Nein, davon ist im Patch nichts zu sehen. Die Beobachtung basiert vermutlich auf alten Einstellungen mit der IP-Adresse der lan-Bridge.

 

[f-user]

Stimmt. Ausgerechnet diese Zeile habe ich beim Übertragen des Patches übersprungen...

Danke!

Habe das nachgeholt. Jetzt funktioniert es so, wie man es von dem Patch her erwarten würde. D.h. die IP-Adresse wird (noch) nicht automatisch von lan ausgelesen.