debug.cfg verschwindet

Kann es sein, dass die Fritzbox mit der aktuellen Firmware irgendwelche Ports gar nicht mehr zulässt/sperrt?
Das müßten dann aber schon sehr spezielle Ports sein, hier (kein freetz) laufen Dienste auf 22 (dropbear), 8088 (busybox httpd) und 1234 (egal was) vollkommen unauffällig, mit passender fwrule auch extern in Richtung WAN.

Mach doch einfach mal ein "netstat -anp" und zeige den relevanten Teil Deiner apache-Konfiguration.

PS: Bei Gelegenheit aktualisiere mal bitte die Signatur, dann muß man nicht im Text nach dem Modell und der Version suchen, danke.
 
OK, das ist schon mal eine gute Information, es müsste also funktionieren. netstat war eine super Idee, den Befehl hatte ich schon wieder vergessen.

Einziger Unterschied des Outputs sind folgende zwei Zeilen, die nach Starten meines Skriptes hinzugekommen sind:
Code:
tcp        0      0     0.0.0.0:3690        0.0.0.0:*                LISTEN      2002/svnserve
tcp        0      0     :::85               :::*                     LISTEN      2006/apache2

Allerdings wird auch folgende Info gezeigt
Code:
tcp        0      0     :::80               :::*                     LISTEN      1176/ctlmgr
tcp        0      0     :::443              :::*                     LISTEN      1176/ctlmgr
Port 80 wird also scheinbar nun per default auf den ctlmgr gemappt. Das war vorher nicht so (meine ich) und ist sehr blöd, da mir aufgrund einer externen Firewall nur Port 80 und 443 zur Verfügung steht.

Nachdem ich das Skript gestartet und netstat aufgerufen hatte, kam bei dem Aufruf von "fritz.box:85" (ohne externe Firewall) keine Antwort. Ich vermute fast, dass mein kompilierter apache2 evtl. nicht mehr mit der neuen Firmware zusammen läuft.
 
Zuletzt bearbeitet:
Das scheint wohl der Fehler zu sein: Mit den Kompilaten von fritzmod und leicht abgeänderter Config schickt der apache nun eine Antwort auf die Anfrage :motz:
 
@kmeleon:
Auf 80 war der ctlmgr praktisch schon immer aktiv, da er den internen HTTP-Server des FRITZ!OS realisiert. Neu ist allerdings tatsächlich das Lauschen des ctlmgr auf 443 (genauer, auf dem eingestellten Fern"wartung"sport, der für jeden externen HTTPS-Zugriff benutzt wird) auch dann, wenn man gar keine Fernwartung aktiviert hat. Damit kann man jetzt intern HTTPS auch dann benutzen, wenn man keinen externen Zugriff zuläßt. Der interne Port 80 läßt sich - wenn man unbedingt seinen eigenen Web-Server auch intern auf diesem Port betrieben will - auch in der ar7.cfg ändern, genau wie der HTTPS-Port (da geht's auch per GUI).

Die netstat-Ausgabe zeigt auch gut den Unterschied zwischen dem reinen IPv4-Listener und einem "allgemeinen", dem das zugrunde liegende IP-Protokoll egal ist.

Heißt denn "Antwort auf die Anfrage" nun, daß auch der SVN wieder geht oder bist Du da noch am Suchen ?

OT und "my 2 cents":
Ich würde auch jedem empfehlen, sich seine Software für die FRITZ!Box selbst zu übersetzen (mit wirklich nur ganz ganz wenigen Ausnahmen, wenn etwas prinzipbedingt unbedingt zum Download bereitgestellt werden muß und man keinen eigenen Webspace hat und das mehr eine "One-Click-Solution" ist).

Ohne r@d jetzt zu nahe treten zu wollen, aber eine Software zu verbreiten, bei der der Empfänger sich auf so viele Faktoren auf einmal verlassen muß, vollkommen ohne Möglichkeit einer eigenen Kontrolle, ist schon etwas kritischer zu sehen als der Reflex von vielen: "Toll, spare ich mir die Arbeit.".

Abgesehen davon, daß da offensichtlich aus einer gewissen Anonymität heraus - der Name steht zwar da, aber wie findet man den Mann ? Das Angebot ist ja nicht illegal - diese Binaries angeboten werden, wie willst Du jemals überprüfen, ob diese Binaries auch nur genau das machen, was sie vorgeben ? Es fehlt bei jedem Angebot die Möglichkeit der Kontrolle. Selbst wenn daneben stehen würde: "mit XYZ am 26.08.2014 um 07:12 Uhr mit diesen Einstellungen kompilliert", wäre der Aufwand das zu überprüfen extrem hoch (man suche nur mal nach "truecrypt" und der Story zur Überprüfung der binär vertriebenen Version).

Wenn es einem Angreifer gelingen sollte, die dort bereitgestellten Binaries gegen eigene auszutauschen (das muß ja nicht einmal r@d selbst sein, das könnte jeder beliebige Angreifer sein, der eine der immer mal wieder aufkommenden 0-Day-Lücken im dort verwendeten Wordpress ausnutzt), was wegen fehlender Hash-Angaben - die natürlich auch woanders verifizierbar sein müßten als nur auf derselben Wordpress-Seite - wohl niemandem auffallen würde, dann hat er schon mal einige FRITZ!Boxen mehr "in seiner Gewalt".

Es reicht beim FRITZ!OS schon ein simples "touch" (in irgendeinem Binary als (f)open leicht zu realisieren) für eine bestimmte Datei, damit die FRITZ!Box total die Orientierung verliert und nicht mehr weiß, wo innen und wo außen ist. Da wird ein eingestellter HTTPS-Zugriff aus dem Internet für die FRITZ!Box bei der Berechtigungsprüfung sehr schnell zu einem aus dem LAN. Dann braucht es nicht einmal so "komplizierte Sachen" wie knockd o.ä.; wenn man da auch Software in binärer Form aus einer - ich sag mal "unbekannten" - Quelle installiert hat, die Zugriffe aus dem Internet per se (als ihre Aufgabe) ermöglichen soll, wird man nicht einmal von den neuen Meldungen im FRITZ!OS zu den Portweiterleitungen überrascht sein.

Insofern ist jeder Tipp zur Konfiguration und Verwendung zusätzlicher Software auf der FRITZ!Box sicherlich willkommen und für viele auch hilfreich, das Bereitstellen von Binaries in der praktizierten Form finde ich persönlich grenzwertig und staune immer wieder über die Gutgläubigkeit einiger Zeitgenossen.

Sich diese Binaries aus dem Freetz-Trunk selbst zu übersetzen (dazu muß man ja noch nicht gleich auch ein Firmware-Image mit freetz-mod verwenden wollen, das verwechseln leider viele und schrecken vor der "endgültigen" Modifikation der Firmware zurück), ist nun wirklich keine höhere Mathematik ... und wer einer Konfigurationsanleitung auf fritzmod.net folgen kann, sollte sich auch seine eigenen Binaries kompilieren können, unter Verwendung von Source-Code aus vertrauenswürdigen Quellen. Die Hash-Prüfung von Dowload-Files dient ja nicht nur der Versionskontrolle ... auch wenn das immer noch anzutreffende MD5 da sicherlich nicht mehr der neueste Schrei ist, es stellt auch sicher, daß die Quellen nicht einfach von irgendjemandem modifiziert wurden.
 
Zuletzt bearbeitet:
@PeterPawn
Dem kann ich nur vollumfänglich zustimmen, Danke!

Verstehe auch nicht warum man sich so oft vor Freetz "drückt", so schwer ist es ja nun auch nicht und wie du schon geschrieben hast muss man ja auch nicht unbedingt ein Freetz-Image auf der FritzBox einsetzen.
 
@PeterPawn:
Ahh, OK, das mit dem Port 80 wusste ich noch nicht. Hätte erwartet, dass es genau andersherum (also 443 standard-mäßig aktiv anstatt 80) ist.
Man kann den Port 80 auch über die GUI konfigurieren (falls Du das meintest), zumindest ging das bei mir.

Inzwischen funktioniert subversion glücklicherweise wieder über den apache2. Es lag wohl wirklich an dem Kompilat: Da hat mein Shared-Library-Setup wohl mal wieder Probleme gemacht. Nachdem ich die aktuelle freetz svn-Revision ausgecheckt habe und alles für diese Firmware neu kompiliert habe, läuft wieder alles wunderbar.

Dass jeder seine eigene Software kompilieren sollte, kann ich nur bestätigen. Ich traue da lieber einem selbst kompilierten Programm. Und freetz ist wirklich GENIAL und einfach. Ich hatte erst vor, das komplette freetz-Image zu installieren (wegen des Wegfalls der debug.cfg), habe aber dann darauf verzichtet, weil ich ja die Box gerade erst neu gekauft habe und nicht auf die 5 Jahre Garantie verzichten möchte. Ich habe keine Hinweise dazu finden können, ob AVM nachträglich festellen kann, ob mal eine andere Firmware auf dem Gerät installiert war. Das schöne an freetz ist, dass es auch dann hilfreich ist, wenn man nicht das Image komplett ersetzen möchte. Ich kann mit dem Wegfall der debug.cfg leben und werde vielleicht mal die calllog-Geschichte ausprobieren.

Eine Sache bei der fwrule-Konfiguration möchte ich hier noch kurz erwähnen:

Richtet man zuerst ein "virtuelles" Interface mit der IP 192.168.1.254 ein, öffnet anschließend die GUI und versucht dort Port 80 an Port 85 des virtuellen Interfaces weiterzuleiten, so bekommt man eine Fehlermeldung, dass dieser Port von der Fritzbox genutzt wird und nicht konfigurierbar ist. Löscht man das Interface jedoch nun, konfiguriert den Port in der GUI und erzeugt anschließend das Interface, so funktioniert alles wunderbar. An dieser Sache bin ich fast verzweifelt, da ich die ar7.cfg-Datei nicht selber verändern wollte. Ich habe noch keine Ahnung, was nach einem Reboot passiert, aber selbst, wenn ich das jedes Mal neu konfigurieren und den apache neu starten muss, kann ich damit leben.

Subversion auf einer Fritzbox ist soooooooo geil, wenn man öfter mal Quellcode global einchecken oder abrufen möchte! Die FritzBox ist einfach genial!
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,868
Beiträge
2,219,771
Mitglieder
371,585
Neuestes Mitglied
PauSchmitz
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.