[HowTo] Fritzbox 7590 Port 443 bereits belegt vom ctlmgr. Eigene Dienste (SSLH/SSH) auf Port 443 auf der 7590 erreichbar machen.

[R0cket]

EDIT: Lösung siehe weiter unten!

Hallo,

ich habe neuerdings von einer 7390 auf eine 7590 geupdated und einige Dienste laufen nicht wie gewohnt.

Mir war aufgefallen, dass SSLH auf der 7590 nicht startet. Der Grund ist, dass ich SSLH oder zumindest SSH u.a. auf Port 443 laufen lassen MUSS. Auf der 7390 habe ich dafür den Port für den SSL Zugriff auf die WebUI auf einen anderen Port gestellt, so dass Port 443 frei war und dann SSLH auf Port 443 laufen lassen und alles war OK. SSLH hat dan alles weitere gemacht.

Auf der 7590 bleibt der Port 443 von der Fritzbox belegt, auch wenn man den WebuI SSL Port ändert. Laut Netstat ist der Port 443 von ctlmgr belegt.

Hier wird in etwa das Problem Beschrieben:

[Problem] - [7590] AVM-Gui https Freigabe, Freetz-Portfreigaben, SSLH funktionieren nicht

Hallo Zusammen, neue Box, viele Fragen ;-) Ich habe die 7590 mit dem trunk (14604) gebaut unter anderem auch mit 'dnsmasq'. Für eine bessere Übersicht habe ich die config angehangen. Ich habe verstanden, dass Freetz für diese Box noch experimentell ist, trotzdem möchte ich meine Probleme...

www.ip-phone-forum.de

[Problem] - Port 443 wird intern nicht freigegeben für Portforwarding

Hallo, meine 7490 mit LaborFW macht kein Portforwarding an Port 443, allerdings nur aus dem internen Netz. Von extern über die MyFritz-Adresse wird der Port jedoch weitergeleitet. Ich finde keine Möglichkeit das zu ändern. Bei Freigabe des Fernzugriffes über HTTPS wird ja ein zufälliger Port...

www.ip-phone-forum.de

AVM hat wohl als "feature" eingeführt, dass die WEBUI intern auch immer über SSL erreicht wird, ob man das will oder nicht. Der riesen Nachteil ist, dass der oftmals einzige offene Port 443 dauerhaft belegt ist. Was das für ein monumentales Problem ist, wenn man hinter einer Firewall sitzt, die nur Port 443 offen hat, will ich hier nicht weiter erläutern.

In den post oben wurde geraten den ctlmgr über:

ctlmgr -s

zu stoppen.

bei mir macht die Box aber den Port 443 trotzdem nicht frei. Auch ist es nicht ideal den ctlmgr abzuschlaten.

Ich kann in der Fritzbox Portforwards von Port 443 auf Geräte hinter der Fritzbox leiten lassen, was gegenwärtig meine Ausweichlösung ist, aber nicht Dauerzustand sein soll, da dazu ein weiteres Gerät dauerhaft laufen muss, wass ich vermeiden will. Auf der 7590 soll ein ssh server laufen, der auf Port 443 hört. SSLH habe ich im Einsatz, da ich nur Port 443 nutzen kann, und daher den port 443 für mehr als nur SSH verwenden will.

Wie mache ich dass nun auf der 7590, wenn die Box nun den Port 443 nun selber dauerhaft belegt?

Das Paket AVM-Forwarding ist nicht auswählbar, wenn man freetz fpr die 7590 builden will. Wie mache ich nun Port forwards of die Box selber?

Es ist ein riesen Nachteil, wenn man keine eigene Anwendungen mehr auf der Box auf Port 443 laufen lassen kann.

Gibt es dazu bereits eine Lösung?


Lösung:

Hinweis: Die Befehle am besten mit ; zusammenfassen, damit die Dämonen nicht alles wider überschreiben:

ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot

Also ingesamt:

cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
vi /var/tmp/ar7.cfg
unter:
voip_forwardrules

Neue Zeile einfügen mit: o

"tcp 0.0.0.0:443 0.0.0.0:943";

ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot

ESC und :wq

EDIT: Wichtig ist, dass man die Port Forwards von "aussen" testet und nicht von Netzwerk der Fritzbox selber. Denn intern wird nichts geforwarded und man fragt ständig ssh beim ctlmgr auf Port 443 an, was der natürlich verweigert und wundert sich, warum das ganze nicht funktioniert, obwohl alles richtig eingestellt ist..

 

[PeterPawn]

Hast Du denn bereits versucht, den Service intern an einen anderen Port zu binden (das muß er nun mal können, sonst sollte man sich einen anderen Service dafür suchen) und dann per "voip_forwardrules" in der "ar7.cfg" eine Weiterleitung von extern 443 auf diesen anderen Port einzurichten? Dazu muß zwar IP-Telefonie ebenfalls aktiviert sein (weil sonst die Einstellungen von dort gar nicht berücksichtigt werden), aber wenn das am Ende als "Ausschlußkriterium" herhalten muß/soll: "Einen Tod muß man eben sterben." und dafür reicht auch irgendeine x-beliebige SIP-Registrierung, notfalls auch eine per VPN irgendwohin.

Ansonsten sollten (afaik) die Freigaben über diesen Parameter in der "ar7.cfg" auch in den Versionen bis 07.12 immer noch funktionieren ... die früher verfügbare Alternative, das über die "vpn.cfg" freizugeben, funktioniert ab 07.08 (wenn ich mich richtig erinnere (kann auch schon davor gewesen sein), das habe ich damals jedenfalls irgendwo bei den Unterschieden zu Vorgängerversionen festgehalten, wenn man es genau nachlesen wollte - so man den Beitrag findet, was mittels einer Suche nach den "forwardrules"-Parametern mit überschaubarem Aufwand machbar sein sollte) wohl nicht mehr richtig und am VPN ändert AVM für die/in der 07.19 ja auch wieder gerade heftig herum, so daß ich mich für künftige Versionen auch nicht erneut darauf verlassen würde.

Theoretisch läßt sich auch "internet_forwardrules" weiterhin verwenden, aber - zumindest nach meinen eigenen Erfahrungen - da überschreibt die Box dann auch mal vorhandene Einstellungen, wenn man an den "Internetzugangsdaten" etwas ändert. Das ist - wieder mir zumindest, aber ich habe auch nichts von anderen dazu gelesen, wenn sie die Bearbeitung der Dateien sauber ausgeführt hatten - bei den "voip_forwardrules" noch nicht passiert.

Bei

bei mir macht die Box aber den Port 443 trotzdem nicht frei.

kannst Du Dich eigentlich nur geirrt haben ... denn wenn der Prozess des "ctlmgr" gar nicht läuft, kann er auch den Port nicht belegen (dann taucht der auch im "netstat" nicht mehr auf). Wenn Du mit "macht nicht frei" aber wieder meinst, daß auch dann per GUI keine externe IPv4-Freigabe für Port 443 eingerichtet werden kann, dann paßt das gar nicht erst zusammen, da der "ctlmgr" ja unbedingt laufen muß, damit das GUI überhaupt funktioniert - schließlich ist er auch dafür zuständig.

 

[R0cket]

EDIT: Um meine eigene Frage zu beantworten: Nein es gibt keinen Konflikt. Port Forward und Port Listening sind unabhängig voneinander. "ctlmgr" wartet weiterhin auf Port 443 und blockiert damit den Port 443 als Listening Port. Somit mus man als Listening Port sich einen anderen ausdenken.

Port Forward kann man aber 443 forwarden wohin man will, also bspw. auf den sich ausgedachten. Dann muss man SSLH oder was auch immer auf diesen ausgedachten port hören lassen.


Gibt es dann nicht einen Konflikt? Das Problem ist doch, dass der "ctlmgr" auf Port 443 höhren will. Muss ich nicht zu erst dafür sorgen, dass der "ctlmgr" das nicht mehr macht, wie ich das in der Vergangenheit mit dem ssl webui gemacht habe, damit der Port frei ist für andere Dienste? Oder ist das "Port Forwarden" unabhängig vom "Port Listening"?

Wenn ich port 443 auf bspw. Port 444 umleite und dann SSLH darauf hören lasse sollte das klappen? Und das Listening vom "ctlmgr" auf Port 443? Was passiert damit? Geht das ins leere? So habe ich das eigentlich nie gesehen, aber werde ich mal testen.

-- Zusammenführung Doppelpost by stoney

Juhuu das hat geklappt!

PeterPawn du bist ein wandelndes Lexikon. Vielen Dank für die Hilfe.

Hinweis: Die Befehle am besten mit ; zusammenfassen, damit die Dämonen nicht alles wider überschreiben:

ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot

Also ingesamt:

cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
vi /var/tmp/ar7.cfg
unter:
voip_forwardrules

Neue Zeile einfügen mit: o

"tcp 0.0.0.0:443 0.0.0.0:943";

ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot

ESC und :wq

 

[Mathias-R]

Hinweis: Die Befehle am besten mit ; zusammenfassen, damit die Dämonen nicht alles wider überschreiben:

ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot

Hallo,
mir ist es bei einer 7590 mit 7.12 nicht gelungen die ar7.cfg zu ändern. Nach jedem Reboot sind meine Zeilen wieder weg, auch mit der hier beschriebenen Methode. Als Workaround habe ich in der Benutzeroberfläche Forwardings auf eine nicht existierende IP eingerichtet und diese dass mit ifconfig -a lan:3 192.168.178.3 der Fritzbox zugewiesen. Gibt es hier noch einen Trick?
Kann man die Datei notfalls temporär per Script mit sed patchen und neu einlesen lassen?
Gruß, Mathias

 

[R0cket]

Interessant, ich kannte den Befehl nicht. Ich dachte -a listet nur die Infos aus. Aber wenn man das so machen kann, dann ergeben sich ganz neue Möglichkeiten.

 

[Mathias-R]

Hallo,
nachdem es mir unter OS 7.12 nicht gelungen ist die angepasste ar7.cfg einzuspielen habe ich ein FritzOS 06.92 in die andere Partition eingespielt. Zwar hat auch hier nicht der Weg mit "ctlmgr -s; voipd -s; cp /var/tmp/ar7.cfg /var/flash/ar7.cfg; reboot" funktioniert, aber dafür ein "cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg && ar7cfgchanged". Jetzt sind die Änderungen auch nach einem reboot noch da. Nach einer Umschaltung im adam2 auf das aktuelle System 07.12 ist damit alles OK.

Gruß, Mathias

 

[PeterPawn]

Vorweg mal eines ... mein Beitrag #2 (der auch keinerlei Bezug auf das richtige Editieren von TFFS-Nodes nimmt) stammt vom 10.01.2020 12:44 Uhr und die letzte Bearbeitung von #1 erfolgte erst am 10.01.2020 14:26 Uhr - das zeigt auch kein "What's new" mehr an, wenn man so etwas nachträglich ändert und damit bleiben solche Änderungen (egal ob richtig oder falsch) dann oft unbemerkt.

Normalerweise widerspreche ich ja solchen falschen "Anleitungen" (oder eher "Auflistungen von Befehlen", denn zu einer Anleitung gehört (für mich zumindest) auch eine Erklärung, was da eigentlich passiert und was dabei schiefgehen könnte bzw. wie man dann reagiert) umgehend, wenn ich sie sehe und hier kann man auch mal wieder illustrieren, warum das durchaus Sinn macht, selbst wenn es in Arbeit ausarten kann, in solchen Nacherzählungen von Anleitungen dann nach dem Vorhandensein von Fehlern zu fahnden ... und nein, das ist nicht nur Besserwisserei, denn wie es anderen ansonsten ergeht, kann man sich hier in #4 ansehen.

Denn das ist auch alles eher wenig verwunderlich bzw. wieder mal "Glück gehabt", was da in #4 und #6 berichtet wird.

Das Kopieren von Daten in einen TFFS-Node per "cp" funktioniert (und das ist auch schon lange bekannt, sogar bei AVM gibt es deshalb das "nvi"-Skript in der Firmware:

#! /bin/sh
if [ -z "$1" ] ; then
        echo "use: $0 <config-filename>"
        exit 1
fi
cat $1 >/var/nvi.tmp && vi /var/nvi.tmp && cat /var/nvi.tmp >$1
rm -f  /var/nvi.tmp

) überhaupt nicht ... insofern ist schon der Teil, der hier nachträglich per "Bearbeiten" ergänzt wurde, deutlich falsch, was das Kopieren ins TFFS angeht. Das KONNTE also eigentlich gar nicht funktionieren (ist auch reproduzierbar) und man stellt sich die Frage, wie es bei @R0cket funktioniert haben sollte - u.U. war hier die Unkenntnis über den Unterschied zwischen einer regulären Datei und einem TFFS-Node der Auslöser ... mangels Masse in der Erklärung läßt sich das halt schwer einschätzen.

Denn nach dem "cp" steht natürlich trotzdem eine reguläre Datei mit dem richtigen Inhalt unter dem verwendeten Namen im Dateisystem (da, wo zuvor der Inode für das "char device" zu finden war) ... nur überlebt diese einen Neustart nur unter sehr, sehr seltenen Umständen, nämlich wenn die "config"-Partition zum persistenten Speichern der Inodes für die Char-Devices der TFFS-Nodes genutzt wird und eine bereits vorhandene "reguläre Datei" beim nächsten Systemstart nicht erneut durch "char devices" überschrieben wird. Auf diesem Weg landen die geänderten Daten jedenfalls ziemlich sicher nicht in dem richtigen TFFS-Node und die Ergebnisse und Folgen sind ein wenig abhängig vom verwendeten Modell und der FRITZ!OS-Version.

Beim zweiten Ansatz wird dann zwar richtigerweise per "cat" ins TFFS geschrieben ... aber bei der Verwendung von "ar7cfgchanged" ist man - wie vor Gericht und auf hoher See - "in Gottes Hand" und es ist eher Zufall, ob die Änderungen am Ende auch persistent sind oder nicht. Warum ist das so?

Schaut man in die "ar7cfgchanged" hinein (das ist ein Einzeiler als Shell-Skript), sieht man folgendes:

#!/bin/sh

exec /etc/init.d/rc.net reload

Dröselt man sich dann den Ablauf beim "reload" in dieser Datei "rc.net" weiter auf, sieht man, daß da der "ctlmgr" gar nicht gestoppt wird.

Ja, i.d.R. wird dieses Skript heutzutage beim "reload" auch vom "ctlmgr" aufgerufen und da würde dessen Beenden auch dem Skript "rc.net" nicht wirklich weiterhelfen können:

vidar:/home/FritzBox/FB7490/firmware $ strings 113.07.12-70401/lib/libcmapi.so | grep "rc.net"
/etc/init.d/rc.net reload
vidar:/home/FritzBox/FB7490/firmware $ strings 113.07.19-75207/lib/libcmapi.so | grep "rc.net"
/etc/init.d/rc.net reload
vidar:/home/FritzBox/FB7490/firmware $

... die "libcmapi.so" ist Teil des (mittlerweile ausgelagerten) API des "ctlmgr" und der Punkt beim "grep" in "rc.net", findet natürlich auch den Punkt selbst - daher ist kein "escape" dafür erforderlich.

Damit behält der "ctlmgr" - wenn das "rc.net"-Skript nicht von ihm selbst aufgerufen wurde, sondern über "ar7cfgchanged", denn ansonsten kann/könnte er natürlich auch selbst dafür sorgen, solche Dateien neu einzulesen - aber den alten Inhalt der Dateien im Speicher und wenn man dann nicht wenigstens noch einen Neustart einschiebt (und dabei dann das erwähnte Glück hat, daß der "ctlmgr" keine Änderungen an dem Inhalt der geänderten Datei mehr vornimmt, wenn er selbst gestoppt wird), sind die eigenen Änderungen spätestens beim nächsten Schreibzugriff des "ctlmgr" auf die geänderte Datei auch wieder Geschichte.

Wirklich sicher (zumindest bei korrekter Anwendung) ist es tatsächlich, die betroffenen Daemons während des Überschreibens der Datei (bzw. des "TFFS-Stroms") zu beenden und erst danach erneut zu starten ... ob man tatsächlich die ganze Box neu starten muß/sollte, hängt auch von den Änderungen ab und von den eigenen Kenntnissen, welche Daemons denn von den geänderten Einstellungen überhaupt beeinflußt werden. Insofern kann man gegen ein "reboot" zwar nicht wirklich etwas einwenden ... außer eben, daß es wohl in der Mehrzahl der Fälle schlicht überflüssig wäre. Andererseits stellt es wenigstens auch bei den "Ungeübten" sicher, daß die durchgeführten Änderungen einen Neustart tatsächlich überleben bzw. überlebt haben.

Die Notwendigkeit des Stoppens beim "ctlmgr" ergibt sich aus dem Cachen der Konfigurationseinstellungen durch ebendiesen Daemon ... bei anderen Daemons ist das eher eine Frage, ob diese dann von den Änderungen Notiz nehmen, denn das machen sie entweder bei einem "reload" (einige Daemons, u.a. der "voipd", kennen passende Parameter bzw. Signal-Handler) oder bei einem Neustart. Insofern ist auch die Zusammenstellung von Kommandos in #1, die sowohl den "ctlmgr" als auch den "voipd" stoppt und danach dann trotzdem die gesamte Box neu startet, eher Kohl ... auch wenn sie halt nicht wirklich "schädlich" ist, wie das unausrottbare "debug bin" beim MS-FTP-Client. Das würde also auch ohne das Stoppen des "voipd" genauso funktionieren, denn der hat (afaik) keinen eigenen Zwischenspeicher für irgendwelche Einstellungsdateien - zumal da auch das Cachen weniger lohnend erscheint, denn die sind ja relativ statisch (mal von der Anrufliste abgesehen, die ist aber wieder ein gänzlich anderes Thema und nicht mal richtig Sache des "voipd").

Nur sollte man dann eben auch die richtigen Kommandos zum Überschreiben des Inhalts eines TFFS-Nodes verwenden und das ist eben KEIN "cp". Ersetzt man das in #1 durch ein "cat changed_file > tffs_node", wie es in #6 vor dem "ar7cfgchanged" gezeigt wird, funktioniert der Rest dann aber auch wieder deutlich sicherer und ist reproduzierbar ... während es beim "ar7cfgchanged" von der Fortsetzung und auch von etwas Glück abhängig bleibt - und auch von der Zeit, die man für die eigene Bearbeitung braucht(e), denn je länger es dauert, um so mehr steigt die Wahrscheinlichkeit eines zusätzlichen Schreibzugriffs; außer man braucht dann wieder sooo lange, daß man die eigenen Änderungen erst dann fertig hat, wenn der "ctlmgr" schon das nächste Mal die Änderungen ins TFFS synchronisiert hat und man dann selbst diese Änderungen über den "ctlmgr" wieder überschreibt -> die Schreib- und Lesezugriffe auf das TFFS kann man sich im "procfs" ansehen.

Auf alle Fälle sind solche Kopfstände, wie sie in #6 berichtet werden, deutlich übertrieben ... auch wenn viele Wege nach Rom führen mögen, muß man von Berlin ja nicht unbedingt den über Tokio führenden nehmen (schon gar nicht zu Zeiten, in denen extreme Reisebeschränkungen gelten).

 

[Mathias-R]

@PeterPawn Danke für die sehr ausführliche Erklärung!

Immerhin ist damit klar, dass der Weg aus #1 so nicht funktionieren konnte. Ich hätte mir den Umweg über die alte Firmware aber sparen können, der Fehler lag nur im cp statt cat.

Gruß, Mathias

 

[R0cket]

So ich muss das Thema mal wieder ausgraben.

Ich war ein paar Tage unterwegs und konnte mich auf einmal nicht mehr mit ssh auf meine FB verbinden.

Zurück heim, habe ich nach einigen Troubleshooting schnell festgestellt, dass das Problem darin lag, dass die Port Weiterleitung auf die Fritzbox in ar7.cfg unter voip_forwardrules verschwunden war und somit keine meiner server dienste mehr erreichbar waren. Ich habe dann nach der im ersten Post beschriebenen Methode mein Portforward wieder eingefügt, was sofort auf ANhieb geklappt hat und alles funktionierte wieder wie es sollte.

Was mich nun wundert ist, wie konnte das einfach so von selbst passieren, dass der Eintrag unter voip_forwardrules gelöscht wird? Ich habe die ar7.cfg zuletzt im März geändert und seit dem nicht mehr angerührt und jetzt wurde der Port forward einfach so von selbst gelöscht?! Und dass wo ich unterwegs bin?

Wenn die Fritzbox einfach so diese extrem wichtigen port forwards selbständig löscht, habe ich ein riesiges problem. Ich muss mich immer darauf verlassen können, dass ich von überallher sicher auf meine Server zuhause zugreiffen kann. Wenn die Fritzbox von sich aus auf die Idee kommt einfach diese Port forwards zu löschen, ist das eine Katastrophe.

Wie kann ich feststellen, wieso diese port forwards gelöscht wurden und wie kann ich sicherstellen, das so etwas nicht nochmal passiert.

Und gibt es mitlerweile eine andere methode protforwards auf die fritzbox einzurichten als als die voip_forwardrules methode?

 

[baerenbisch]

Was mich nun wundert ist, wie konnte das einfach so von selbst passieren, dass der Eintrag unter voip_forwardrules gelöscht wird? Ich habe die ar7.cfg zuletzt im März geändert und seit dem nicht mehr angerührt und jetzt wurde der Port forward einfach so von selbst gelöscht?! Und dass wo ich unterwegs bin?

Ich grabe es auch nochmal aus.
Die Änderung der ar7.cfg könnte in Deinem Fall ein Firmwareupdate "von außen" gewesen sein. Mir ist das auch so passiert.

Zum eigentlichen Thema sieht es bei mir so aus dass ich die Portveränderungen in der ar7.cfg hinbekommen habe. Das
AVM Webinterface meldet sich jedoch trotzdem sobald per HTTPS auf die Box zugegriffen wird. Um den auf der Box
laufenden webserver (lighttp) auf Port 443 antworten zu lassen muss explizit "ctlmgr -s" ausgeführt werden. Nach einem reboot
stehen zwar die Portregeln weiter wie geändert aber der ctlmgr läuft eben auch wieder. Immerhin startet ebendieser nach
"ctlmgr -s" nicht wieder von alleine (wie wenn er mit kill -9 abgeschossen wird) aber schön wäre doch diesen "Dienst" dauerhaft
außer Gefecht setzen zu können ....

 

[FischersFreetz]

Ich habe die hier vorgeschlagene Lösung auch mal ausprobiert und konnte sie (bei einer 7590 FW 7.27 mit Freetz-NG) nicht erfolgreich nachstellen (siehe hier mehr dazu).

... aber schön wäre doch diesen "Dienst" dauerhaft außer Gefecht setzen zu können ....

Ein ctlmgr -s (am Ende des Bootprozesses) setzt ihn doch dauerhaft außer Gefecht. Oder?
Aber, ob das auch dauerhaft wirklich so eine gute Idee ist, ...?

 

[baerenbisch]

Ein ctlmgr -s (am Ende des Bootprozesses) setzt ihn doch dauerhaft außer Gefecht. Oder?

Ja so ist es. Ich müsste aber den ctlmgr -s vor dem starten von lighttp ausführen. Solange der ctlmgr läuft verweigert der lighttp seinen Start
wegen belegter Ports ...

 

[PeterPawn]

@baerenbisch:
Vielleicht wäre es ja hilfreich, wenn Du mal genauer erklärst, was da auf Port 80 und 443 eigentlich "serviert" werden soll und für wen und von wo solche Zugriffe künftig erfolgen sollen.

Ein Betrieb des FRITZ!OS ohne aktiven ctlmgr ist jedenfalls keine wirklich gute Idee und vermutlich auch keine, die dauerhaft gut gehen kann. Denn der ist nun mal DIE zentrale Komponente im FRITZ!OS (auch wenn das mittlerweile von AVM immer mehr modularisiert wird) und dient u.a. auch der Kommunikation zwischen anderen Komponenten, weil er tatsächlich das komplette Interface zum Abfragen und Setzen von Werten in der Firmware (und zwar sowohl von persistenten als auch von volatilen) beinhaltet und irgendwann garantiert eine der anderen Komponenten darüber stolpert, wenn sie keine Werte abfragen oder setzen kann. Dann ist der nächste anschlagende Watchdog nicht mehr weit - selbst wenn das GUI, über welches der Besitzer Einstellungen ändern könnte, nicht mehr erreichbar ist. Es gibt ja auch interne Zustandsänderungen, die irgendwann mal in den Einstellungsdateien landen.

Zwar kann man dem ctlmgr auch andere TCP-Ports unterschieben (wobei der ja auch nicht nur auf 80 und 443 lauscht, sondern noch auf jeder Menge anderer Ports -> netstat -antup | grep "\(LISTEN\|udp\).*ctlmgr"|wc -l liefert bei mir 20 offene Ports, die vom ctlmgr bedient werden und da sind die diversen Sockets für die anderen Komponenten gar nicht dabei), aber darüber findet die interne Kommunikation ja auch nicht statt ... dafür werden eben die (UNIX-)Sockets genutzt.

Eine Möglichkeit, die Benutzung des HTTPS-Ports (TCP/443) durch den ctlmgr per Konfigurationsdatei zu "verbieten", gibt es (zumindest nach meinem Kenntnisstand, den gerne jemand mit entsprechenden Tests/Nachweisen auf einen aktuelleren Stand bringen kann) nicht ... zwar kann man in der ar7.cfg den Port für HTTPS festlegen (der dann auch 1:1 extern freigegeben wird, wenn kein PCP-Server dazwischen etwas dagegen hat), aber der Port 443 wird wohl IMMER zusätzlich auch noch belegt - was spätestens beim internen HTTPS-Zugriff auf das GUI ja auch wieder Sinn ergibt, wenn man nicht ständig den Port in den URLs mit angeben muß und das kann sehr mühsam sein, solange AVM keine automatische Weiterleitung von HTTP-Port 80 auf den konfigurierten HTTPS-Port ausführt.

Was man aber eben machen kann, ist die Umleitung des externen Ports 443 (bei IPv4, wobei es bei IPv6 alles noch einmal ganz anders wäre) auf einen anderen internen Port - denn den belegt der ctlmgr eben nicht selbst, solange man nicht auch extern TCP/443 zuweist (was man nicht machen sollte, weil schon eine ausreichende Anzahl an TLS-Handshake-Versuchen schnell zu Ressourcen-Problemen führen kann). Den "normalen" HTTP-Port (TCP/80) sollte man auch heute noch über die ar7.cfg "umbiegen" können ... nur hat das mit dem externen Port auch wieder nichts zu tun.

Da AVM die permanente Benutzung von Port 443 auch erst später eingeführt hat (wann genau, weiß ich nicht mehr, aber für eine längere Zeit war auch intern nur derselbe Port in Benutzung, wie beim externen Zugriff), weiß ich auch nicht (mehr), wie der ctlmgr darauf reagiert, wenn er sich nicht an TCP/443 binden kann, weil ein anderer Prozess den Port schon in Beschlag genommen hat - aber das kann man ja auch testen, dafür reicht schon ein nc -l -p 443 -v &, bevor man den ctlmgr wieder startet (ggf. muß man den Prozess dann abschießen oder etwas senden, damit das netcat beendet wird, falls der ctlmgr den Dienst verweigert).

 

[FischersFreetz]

Ich müsste aber den ctlmgr -s vor dem starten von lighttp ausführen

Vielleicht so in der rc.custom und Starttyp von lighttpd auf (*) Manuell :

ctlmgr -s
/etc/init.d/rc.lighttpd start

Aber wie schon gesagt, ist das dauerhaft wohl keine gute Idee.
Ich würde es eher per script für den Zeitraum "hinbiegen", in dem es so benötigt wird.

 

[baerenbisch]

@ PeterPawn:
Erstmal ein Dank für die Beschäftigung mit meinen wohl eher trivialen Problemen (nebst trivialen Kenntnissen):

Ich möchte auf einer alten Fritzbox (7240, 7362SL, 7390) in einem Netzwerk die Box als Webserver nutzen auf dem eine (erstmal statische) "Homepage"
serviert wird. Klappt wunderbar über Port 80. Nun wäre es schön auch einen Zugriff über HTTPS zu ermöglichen weil sich so viele an der unsicheren
Verbindung stören. Klappt ebenfalls wunderbar aber natürlich mit der obligatorischen Aufforderung ein fremdes Zertifikat zu akzeptieren.
Da alles nichts kosten soll kommt nun letsencrypt ins Spiel und das klappt halt nicht.

 

[PeterPawn]

Mal abgesehen von der Frage, warum es für so einen Webserver überhaupt eine FRITZ!Box sein soll (außer vielleicht, "weil es sie gibt") ... hier hat man m.E. nur die Wahl zwischen Pest und Cholera. Entweder man nimmt ein uraltes FRITZ!OS, was eben den Port 443 intern noch nicht benutzt hat oder man kann diesen Port intern nicht benutzen.

Welche Version genau die Änderung brachte, weiß ich nicht mehr, aber eine Suche hier im Board sollte zumindest Hinweise erbringen, ab wann in etwa auch der Port 443 vom ctlmgr genutzt wurde - das ist nicht sooo lange her (relativ gesehen) und ich würde erst mal bei einer 06.5x mit dem Testen beginnen. Von dort an kann man sich langsam in Richtung neuerer Firmware vorarbeiten - irgendwann nutzt der ctlmgr dann auch den Port 443 IMMER.

So lange die Box dann tatsächlich nichts anderes machen soll (also auch kein WLAN, keine Telefonie, etc.), ist das sicherlich zu vertreten ... aber dann macht es m.E. auch fast keinen Sinn mehr, das mit einer FRITZ!Box (zumindest keiner, auf der auch noch ein komplettes FRITZ!OS läuft) zu realisieren. Dann kann man auch gleich hingehen und das OS so weit abspecken, daß da gar keine anderen AVM-Services mehr arbeiten (außer eben ein SSH-Server für den Konfigurationszugang und der gewünschte HTTP-Server) - bei der 7362SL geht das notfalls sogar, wenn noch ein FRITZ!OS installiert ist.

So, wie man zusätzliche Dienste über die YAFFS2-Partition einbinden kann ins FRITZ!OS, kann man natürlich auch den Rest der Initialisierung (also den originalen Inhalt der /etc/inittab) verändern, so daß die anderen FRITZ!OS-Komponenten gar nicht mehr initialisiert werden. Das kriegt man dann vermutlich auch alles noch in die YAFFS2-Partition gebaut ... zumal man ja auch auf die filesystem_core.squashfs verzichten kann, wenn man die nicht nutzen will. Allerdings sollte man dann eben sorgfältig arbeiten und dafür sorgen, daß es nicht zu viele Schreibzugriffe auf den Flash gibt. Die Inhalte für den Server kann man dann immer noch vom USB-Stick holen ... wobei man dann eben dessen Einbinden auch wieder selbst erledigen muß, wenn die AVM-Komponenten das nicht übernehmen. Andererseits kriegt man dann durch den Verzicht auf andere AVM-Komponenten natürlich auch gleich viel mehr Ressourcen frei für die eigene Verwendung.

Kurz: Um tatsächlich nur einen eigenen HTTP(S)-Server auf einer älteren FRITZ!Box zu betreiben, braucht man ja kein komplettes FRITZ!OS ... und dann stellt sich die Frage der belegten Ports auch automatisch nicht mehr.

 

[baerenbisch]

Ja ich gebe zu: "weil es sie gibt" und weil es bisher seit Jahren mit vertretbar wenig Energieverbrauch super funktioniert hat.
Vielleicht sollte ich meinen Geiz in Verbindung mit Nachhaltigkeit überwinden und einen Raspi oder Verwandten anschaffen.

Nochmals Danke für all die Gedanken!

 

[PeterPawn]

und einen Raspi oder Verwandten anschaffen.

Man KANN das tatsächlich auch alles (sogar einigermaßen unkompliziert) mit einer 7362SL lösen (die würde ich wegen ihres Aufbaus - VR9 + NAND-Flash - bevorzugen) ... nur sollte man dann eben auf FRITZ!OS verzichten bzw. nur dessen Kernel verwenden und den Dateisystem-Inhalt lieber selbst zusammenstellen bzw. ihn gleich weglassen (zumindest als SquashFS-Image). Die paar Kernel-Treiber, die man für udevd und das Mounten von Storage-Devices noch aus dem AVM-Image braucht, darf man sich auch problemlos "ausleihen", denn das sind wieder Kernel-Teile - nur halt keine statisch gelinkten.

Den Rest vom ganzen AVM-Zeugs braucht man gar nicht ... sofern man auf Buttons und LEDs verzichten kann, denn die hat AVM leider auch im Kernel so eingebunden, daß man ohne proprietäre AVM-Komponenten nichts damit anfangen kann (bei vielen Modellen), außer man macht die komplette Ansteuerung selbst (bei VR9 geht das auch noch relativ simpel, erst bei GRX-Boxen wird's schwerer, weil die GPIO-Pins dann über einen Multiplexer laufen).

Man MUSS also gar keinen Einplatinen-Rechner nehmen (solange man nicht mehr Performance braucht) ... nur sollte man dann für eine solche "Eine-Funktion"-FRITZ!Box eben auch kein komplettes FRITZ!OS verwenden. Aber die notwendige Software kann man sich tatsächlich von einem der Freetz-Forks bauen lassen ... nur das damit erstellte System sollte man weglassen (das erweitert das FRITZ!OS ja nur und ersetzt es nicht) und lieber selbst Hand anlegen. Allerdings braucht's dazu dann auch die passenden Kenntnisse ... DAS ist dann bei Einplatinen-Rechnern mit entsprechenden OS-Images doch wieder deutlich einfacher zu handhaben, weil man es nur noch zu konfigurieren braucht und nicht erst selbst zusammenstellen muß.

 

[B612]

Auf der 7590 belegt der ctlmgr unnötigerweise den port 443,

Imo nicht unnötigerweise denn Port 443 wird bei neueren FW Versionen standardmäßig verwendet da https mittlerweile für das WebGUI Standard ist. Bei der 7390 mt 6.8* ist das noch nicht so.