[Info] FRITZ!Box 7490 Labor-Firmware Version 6.10-28144 vom 06.06.2014

[SnoopyDog]

telnetd wird doch durch die entsprechende Kurzwahl über ein Telefon mit #96*7* dauerhaft aktiviert...

 

[Benares]

@robert_s
Ich weiss nicht so recht. Der telnet-Daemon ist da wohl ein schlechtes Beispiel. Den konnte man doch auch über Telefon-Code an-/ausschalten.
Wurde das wirklich in der debug.cfg vermerkt, damit es einen Reboot überlebt? Oder gibt es da noch andere Stellen?

 

[Schlumpfine]

wie SnoopyDog schon sagte: ein via Kurzwahl aktivierter telnetd bleibt dauerhaft aktiv, dass schließt ein reboot der box mit ein.

schreib doch mal in deine debug "touch /var/tmp/debugfueralle" ;-)
dann siehste ob sie funktioniert...

 

[Benares]

Ja, aber die Frage war ja eher, ob beim telnetd wirklich noch die debug.cfg mit im Spiel ist (so war's meines Wissens früher mal), oder ob der Start irgendwo anders vermerkt wird.

Darüber, dass der telnetd bei den neuen Betas einen Reboot nicht mehr überlebt, darüber hat m.W. noch keiner bereichtet. Dass aber andere Anwendungen nicht mehr funktionieren, die die debug.cfg definitiv nutzen (z.B. der LCR) , aber schon. Ich selbst bin nicht betroffen, da ich keine Anwendungen mehr verwende, die das benötigen. Aber es interessiert mich, da ich früher viel damit gemacht habe.

 

[SnoopyDog]

ob beim telnetd wirklich noch die debug.cfg mit im Spiel ist (so war's meines Wissens früher mal)

Nein, noch nie!

 

[suchkuga]

Hallo, ich bin zufällig auf euer Forum hier gestoßen.
Ich bin auf der Suche nach einer Lösung zu meinem Problem:

habe seit kurzem (6 Mte) eine 7490 von 1+1. Sie läuft prima und ich bin mit der Labor Version von Anfang an unterwegs. Die Anbieterdienste sind deaktiviert und bisher echt keine Probleme mit Telefon oder WLAN etc.

Mit den letzten Update auf FRITZ!OS 06.10-28144 BETA hat meine Fritz ein Problem bekommen. Die Zeitschaltung für WLAN sieht vor Ausschalten um 01:00 und Einschalten um 06:20 Uhr. Laut Systemprotokoll wurde das auch so durchgeführt:

08.06.14 06:20:00 WLAN wurde von der WLAN-Zeitschaltung aktiviert (2,4 + 5 GHz).
08.06.14 01:00:02 WLAN-Übertragungsqualität durch reduzierte Kanalbandbreite erhöht (2,4 GHz).
08.06.14 01:00:00 WLAN wurde von der WLAN-Zeitschaltung deaktiviert (2,4 + 5 GHz).

Die WLAN LED ist jedoch aus und meine WLAN-Geräte (4 St.) haben keinen WLAN-Empfang.

178-221-AKOYA-WLAN 192.168.178.221 00:15:AG:9B:0F:9A nicht verbunden
178-92-Compaq-WLAN 192.168.178.92 C4:33:FE:4C:F9:74 nicht verbunden
178-95-Laptop1-WLAN 192.168.178.95 00:1E:68:9E:C3:B6 nicht verbunden
178-98-Laptop2-WLAN 192.168.178.98 F4:AA:E3:F1:C4:77 nicht verbunden

Ich hatte schon ausprobiert die Zeitschaltung auszuschalten, klar WLAN lief durch, alles i.O.
Ein Zurücksetzen auf die alte Version wäre natürlich auch noch möglich, möchte ich jedoch nicht.

Ist dies 'Problem' sonst noch bei einem von euch aufgetreten?
Hat jemand eine Idee für eine Lösung? (ohne Neustart, bzw. Netzstecker ziehen)

Danke

 

[Schlumpfine]

System: NEU - Neue Versionen von FRITZ!OS können automatisch installiert werden (Voreinstellung)*

konnte man das nicht via GUI ausschalten? ich sehe da bei mir keine Option/Haken oder sonst was

 

[Benares]

Findest du unter System, Update im Reiter Auto-Update.

 

[Benares]

Nein, noch nie!

Doch. Bevor es den Telefon-Code gab, wurde telnetd über ein Pseudo-Image aktiviert (telnet-ar7login-reset-debug.tar) und das lief über die debug.cfg. telnetd selbst war m.W. schon immer im Image. Du erinnerst dich?

 

[Schlumpfine]

Findest du unter System, Update im Reiter Auto-Update.

ok, den Reiter will er mir nicht zeigen :-(

Update lief sauber durch. POR wurde gemacht. Browsercache natürlich geleert.

 

[HabNeFritzbox]

Ansicht auch erweitert?

 

[Schlumpfine]

auf "erweitert-erweitert" ? ;-)

wer arbeitet den ernsthaft mit Labors und hat die Ansicht auf "standard" ?

ps: wenn ich die update_auto.lua manuell aufrufe, schmeißt er mich auf die login seite

 

[Benares]

Wenn schon, dann http://fritz.box/system/update_auto.lua
Was kommt nach dem Login?

Aber die 28144 hast du schon installiert, oder? Lt. Signatur ist das nicht so.

 

[HabNeFritzbox]

Wenn man Datei direkt abruft, fehlt die Session ID in der URL. Wenn bereits ein Login ausgeführt wurde, wäre auch die ID mit anzuhängen, sonst neue Session = neuer Login erforderlich.

 

[Benares]

... und ohne Session ID in der URL kommt man halt erst nach Anmeldung auf die Seite, aber direkt.

Der Reiter Auto-Update ist übrigens auch in der Standard-Ansicht da, nur der Reiter "FRITZ!OS-Datei" ist in der Standard-Ansicht ausgeblendet.

 

[Hans Juergen]

d

Ja ist bekannt, findest du in diesem Thread. Nur Neustart hilft. Lass das WLAN einfach an.

 

[Schlumpfine]

Wenn man Datei direkt abruft, fehlt die Session ID in der URL. Wenn bereits ein Login ausgeführt wurde, wäre auch die ID mit anzuhängen, sonst neue Session = neuer Login erforderlich.

selbstredend habe ich ich die richtige URL aufgerufen inklusive aktueller Session-ID ;-)
z. B. http://fritz.box/system/update_auto.lua?sid=9853071af1f1a11b&
selbst wenn ich das ohne Session-ID eingegeben hätte oder diese schon abgelaufen wäre, würde ich eigentlich nach dem Login auf der update_auto.lua landen, weil http://fritz.box/login.lua?page=/system/update_auto.lua&sid=0000000000000000
die Fritte will sie aber perse nicht kennen und schmeißt mich dann auf die Übersicht. Das lua Script ist aber da physisch da wo es sein sollte (hab mal nachgeschaut)

Aber die 28144 hast du schon installiert, oder? Lt. Signatur ist das nicht so.

sofort, umgehend, prioriät 1 => signatur ändern steht nicht auf meinem Schirm! da gibt es Wichtigeres.

 

[PeterPawn]

die Fritte will sie aber perse nicht kennen und schmeißt mich dann auf die Übersicht. Das lua Script ist aber da physisch da wo es sein sollte (hab mal nachgeschaut)

Steht doch alles direkt am Anfang des Lua-Scripts ...

if not config.AUTOUPDATE or config.DOCSIS or "1" == box.query("tr069:settings/UpgradesManaged") or "1" ~= box.query("box:settings/allow_background_comm_with_manufacturer") then
require("http")
require("href")
http.redirect(href.get(http.get_back_to_page()))
end

config.AUTOUPDATE sollte gesetzt sein, config.DOCSIS bei allen Boxen außerhalb der 6000er-Reihe nicht.

Bleibt also noch die Abfrage der anderen Einstellungen:

ctlmgr_ctl r tr069 settings/UpgradesManaged
bzw.
ctlmgr_ctl r box settings/allow_background_comm_with_manufacturer

Kommt beim ersten Kommando eine "1" zurück, wird es ohne Änderungen nicht klappen, genauso wenig wie bei einer "0" bei "allow_background...".

 

[Benares]

Das dürfte Schlumpfine wohl zu hoch sein - mir eigentlich auch. Sieht wohl so aus, als ob es auch davon abhängt, was unter Internet, Zugangsdaten, Anbieter-Dienste eingestellt ist (geraten). Ich hab die FW nur auf einer FB, die als IP-Client läuft.

Hier mal ein Screenshot wie es aussehen müsste

 

[PeterPawn]

Das dürfte Schlumpfine wohl zu hoch sein - mir auch.

Sorry, nicht meine Absicht.

Da Schlumpfine ja offenbar die Kommandozeile bedienen kann (telnet-Screenshot im Beitrag), sollte die Ausführung der beiden ctlmgr_ctl-Aufrufe ja auch kein Problem sein.

Je nachdem, welcher der beiden Aufrufe ein "blockierendes" Resultat liefert, muß man dann andere Gegenmaßnahmen ergreifen.

Wer aber nur die Einstellungen für das Auto-Update abfragen/ändern will, kann auch gleich direkt den ctlmgr_ctl dafür verwenden:

Lesen:

ctlmgr_ctl r updatecheck settings/auto_update_mode

Ausgaben:

1. check
2. update_important
3. update_all

mit der Bedeutung in der Reihenfolge wie im Screenshot von gmeyer.

Setzen:

ctlmgr_ctl w updatecheck settings/auto_update_mode [I]newmode[/I]

Inwiefern jetzt diese Einstellungen die von TR069 überschreiben u.ä., wird sich sicherlich bald zeigen ...

Die Einstellung "allow_background_comm_with_manufacturer", die von einigen im Zuge des Authentifizierungs-Bugs teilweise von Hand in der ar7.cfg geändert wurde, wird (genauer wurde, da ich das bei der aktuellen Version nicht geprüft habe) jedenfalls an vielen Stellen wirklich berücksichtigt. Unter anderem eben auch bei der Abfrage, ob eine neue Firmware-Version vorhanden ist ... wenn man also dort die Kontaktaufnahme mit AVM verbietet, macht auch der Auto-Update-Check nicht viel Sinn.

Die andere Einstellung "UpgradesManaged" sollte eigentlich derzeit auch bei 1&1 noch auf "no" stehen (ich habe nur eine "fremde" Box, auf der ich das prüfen konnte).