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

R0cket

Mitglied
Mitglied seit
20 Sep 2009
Beiträge
367
Punkte für Reaktionen
1
Punkte
18
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:




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
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,099
Punkte für Reaktionen
1,000
Punkte
113
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

Mitglied
Mitglied seit
20 Sep 2009
Beiträge
367
Punkte für Reaktionen
1
Punkte
18
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
 
Zuletzt bearbeitet von einem Moderator:

Mathias-R

Neuer User
Mitglied seit
20 Jul 2005
Beiträge
165
Punkte für Reaktionen
1
Punkte
18
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

Mitglied
Mitglied seit
20 Sep 2009
Beiträge
367
Punkte für Reaktionen
1
Punkte
18
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

Neuer User
Mitglied seit
20 Jul 2005
Beiträge
165
Punkte für Reaktionen
1
Punkte
18
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

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,099
Punkte für Reaktionen
1,000
Punkte
113
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:
Code:
#! /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:
Code:
#!/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:
Code:
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).
 
  • Like
Reaktionen: Mathias-R

Mathias-R

Neuer User
Mitglied seit
20 Jul 2005
Beiträge
165
Punkte für Reaktionen
1
Punkte
18
@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
 
3CX

Statistik des Forums

Themen
235,577
Beiträge
2,062,800
Mitglieder
356,326
Neuestes Mitglied
NuxName