[Info] FRITZ!Box 7270 v2/v3 Beta-Firmware 54/74.06.04-27949 vom 08.05.2014

Status
Für weitere Antworten geschlossen.
Leider bringt ein Pseudo-Image hier nichts, da die Datei /etc/init.d/rc.tail.sh dauerhaft modifiziert werden müsste, damit sie /var/flash/debug.cfg aufruft, was per "mount -o bind" aber nur temporär möglich ist.

Wenn AVM den derzeitigen Software-Stand für das Release festklopft, läßt sich die debug.cfg recht einfach wieder aktivieren.

Ich will die Vorgehensweise bloß nicht vor der "final version" offenlegen, damit sie es nicht doch noch finden und schließen.

Die dafür notwendige Modifikation ist - vorausgesetzt, sie haben nicht noch weitere Lücken in der Authentifizierung - nur mit erfolgreicher Anmeldung an der Box möglich und stellt damit in meinen Augen keine Sicherheitslücke dar, die man an AVM melden müßte.

Würde AVM freiwillig entsprechende definierte Hooks für interessierte Nutzer einbauen, wäre sicherlich allen geholfen, der "Hinweis" schon bei der ersten Telnet-Sitzung ist ja überdeutlich und damit sollte es dann aber auch gut sein.

Offenbar hat man bei AVM über Jahre die debug.cfg geduldet und im Zusammenhang mit dem Bug kriegt man jetzt das große Flattern.

Auch der nunmehr der Vergangenheit angehörende "-c"-Switch bei allcfgconv war ja nicht das Problem ... er konnte lediglich ziemlich einfach zum Auslesen von Klartext-Kennwörtern benutzt werden. Aber auch das sollte - wenn AVM nicht doch noch ein Code-Review ausführen läßt - in der finalen Version noch möglich sein.

Man kann natürlich das Image selbst modifizieren: ...
Aber da kann man auch gleich "freetzen".

Es ist schon ein gewaltiger Unterschied, ob ich lediglich die Software der Box ergänze (z.B. um einen regelmäßigen Webseiten-Aufruf als "alive"-Signal fürs Monitoring oder um einen OpenVPN-Client) oder ob ich gleich ein komplett neues Image flashe.

Schon in minimaler Konfiguration ist ein Freetz-Image ein weitreichender Eingriff, den nicht jeder so haben will ... besonders im SOHO-Umfeld, wo auch gerne mal eine FritzBox für den Heimarbeitsplatz eingesetzt wird.

Und bisher haben debug.cfg-Modifikationen i.d.R. eben auch klaglos Firmware-Updates innerhalb einer Hauptversion überlebt, das ist m.E. ein weiterer wichtiger Vorteil.

Vielleicht überlegt es sich AVM ja doch noch und bietet - ähnlich wie einige NAS-Hersteller - irgendwann mal eine definierte Schnittstelle für Erweiterungspakete an.
 
Moin

@ Smurfoclob: So meinte ich das ja auch gar nicht. Sondern:

1. Im Pseudoimage befindet sich eine Datei Namens: install
2. Dieses ist ein Skript, also die wird ausgeführt wie die debug.cfg.
3. Da die eigenen Startbefehle rein und box damit flashen ohne Neustart anzustossen.

Das ist im Prinzip wie eine Plugin Installation.
 
Wenn AVM den derzeitigen Software-Stand für das Release festklopft, läßt sich die debug.cfg recht einfach wieder aktivieren.
Dann bin ich mal gespannt wie das geht.
Und bisher haben debug.cfg-Modifikationen i.d.R. eben auch klaglos Firmware-Updates innerhalb einer Hauptversion überlebt, das ist m.E. ein weiterer wichtiger Vorteil.
Dem kann ich nur voll und ganz zustimmen. Ich habe bisher auch debug.cfg genutzt um sshd, ftpd, Webserver und manches mehr nachzuladen. Meine Aussage (da kann man doch gleich "freetzen") bezog sich auf den Aufwand.

1. Im Pseudoimage befindet sich eine Datei Namens: install
...
Das ist mir schon klar, bedeutet aber, dass man nach jedem Neustart der Box das Pseudoimage "flashen" muß. Das ist nicht besonders praktisch.

Gruß, SC
 
Ich will die Vorgehensweise bloß nicht vor der "final version" offenlegen, damit sie es nicht doch noch finden und schließen.
Naja, dann machen sie's bei der nächsten Minor ... Hase und Igel.

Würde AVM freiwillig entsprechende definierte Hooks für interessierte Nutzer einbauen, wäre sicherlich allen geholfen, der "Hinweis" schon bei der ersten Telnet-Sitzung ist ja überdeutlich und damit sollte es dann aber auch gut sein.

Offenbar hat man bei AVM über Jahre die debug.cfg geduldet und im Zusammenhang mit dem Bug kriegt man jetzt das große Flattern.
Seufz. Warum AVM seine Boxen vor seinen Kunden mehr verrammeln will, verstehe ich in der Tat nicht. Zumal das dazu führt, daß eben größere Eingriffe in das Default-Image vorgenommen werden. Was dann mittelfristig bedeuten würde, daß un- oder falsch signierte Dateien als FW-Update im Web-UI nicht mehr angenommen würden. Womit dann ruKernelTool mehr Zulauf bekäme, also die Absicherung auch auf der Ebene stattfinden müßte. Watt'n Käse. Kann ich bei Kabelboxen ja noch ansatzweise verstehen, aber bei im Eigentum des Kunden endenden xDSL-Boxen? (Unschön finde ich auch den Wegfall des Modem-Modus'; eine 7490 als xDSL-Modem, dahinter dann eine potentere/bugfreiere Hardware -- was spricht denn dagegen?)
 
Naja, dann machen sie's bei der nächsten Minor ... Hase und Igel.

ist eher unwahrscheinlich, da die 7270 schon längst EOS ist. Es ist nicht mal sicher, ob überhaupt noch eine Final kommen wird.
 
Seufz. Warum AVM seine Boxen vor seinen Kunden mehr verrammeln will, verstehe ich in der Tat nicht. Zumal das dazu führt, daß eben größere Eingriffe in das Default-Image vorgenommen werden. Was dann mittelfristig bedeuten würde, daß un- oder falsch signierte Dateien als FW-Update im Web-UI nicht mehr angenommen würden.
Ist zwar sicherlich OT, aber ich warte bis ich abgewatscht werde:
Wenn das am Ende dazu führt, daß auch für Fritz!Boxen ein Jailbreak notwendig wird ... dann gute Nacht.
Auf der einen Seite setzt sich AVM bei der BNetzA für freie Routerwahl ein (ist ja ihr Marktsegment), andererseits verrammeln sie ihre eigenen Boxen ?
Für mich macht das wenig Sinn oder es zeigt, daß AVM offenbar bei seinen Kundenanalysen bei der Mehrzahl andere Kriterien für die Auswahl eines Routers ermittelt hat, als wir hier im Allgemeinen annehmen. Und sicherlich auch, daß die Bastler AVM eigentlich egal sind, selbst wenn sie seit vielen Jahren neue Einsatzgebiete und die prinzipielle Realisierbarkeit diverser Lösungen aufzeigen und so quasi für AVM die "Forschungsabteilung" entlasten.

Ich konnte es bei älteren Modellen ja noch verstehen, daß AVM aufgrund des beschränkten Platzes oder geringer Reserven in der Leistungsfähigkeit der Hardware keine größeren "Experimente" machen wollte und im Prinzip der Aufbau der Firmware seit Jahren unverändert ist.

Wenn man sich aber _vor_ der Entwicklung eines neuen Produktes in den letzten 2 Jahren einmal ordentlich hingesetzt und über neue Möglichkeiten und Ansätze nachgedacht hätte, wäre *hoffentlich* nicht nur die weitere Fortschreibung alter Zöpfe auch in der 7490 dabei herausgekommen. Das wäre dann sicherlich auch ein tragfähiges Konzept für die Zukunft geworden ...

Mit einer Umstellung von squashfs auf ubifs, dem Einbau einer Paketverwaltung und einer strikten Modularisierung der Funktionen der Software (mit entsprechenden definierten Schnittstellen) hätte man sowohl den hohen Integrationsgrad der FritzOS-Komponenten beibehalten als auch dem Besitzer der Box eine echte Wahlmöglichkeit offerieren können, was er wirklich benötigt. Daß dieses Konzept durchaus erfolgreich sein kann, sieht man z.B. an einigen NAS und den diversen Dreambox-Originalen und -Derivaten. Mit den dabei dann gewonnenen Erkenntnissen wäre sicherlich auch ein Backport dieses Vorgehens mindestens auf die 7390 denkbar gewesen.

So hätte man die unselige Politik, das Image (und sicherlich auch die Box im Betrieb) standardmäßig mit immer mehr Funktionen zu belasten, die der Eigentümer teilweise überhaupt nicht benötigt (z.B. aha), endlich - in eine in meinen Augen sinnvollere Richtung - korrigieren können. Wenn AVM aus der internationalen Version der 7390 den Samba-Server kurzerhand rauswirft (und das muß sehr kurzfristig gewesen sein, wenn man die "schlampige" Umsetzung ansieht), weil der Platz dank aha nicht mehr ausreicht, dann ist das einfach nur Bullshit.

Wenn Marketing (was für tolle neue Funktionen wir bieten !) über Benutzbarkeit siegt (was soll ein "NAS", das vom immer noch am weitesten verbreiteten Client-Betriebssystem nicht mehr direkt zum Speichern von Dateien verwendet werden kann ?), dann stimmt in meinen Augen die Produktpolitik nicht mehr.

Und wozu ein stetiges unkritisches Fortschreiben alten Codes eben auch führen kann, hat man am Bug leider sehr genau sehen können: Durch die ständige Weiterverwendung uralten Codes - offensichtlich ohne daß sich jemand die Mühe machte, diesen vor dem Einsatz in neuen Produkten noch einmal ausreichend zu prüfen - waren Software-Versionen aus fast einem Jahrzehnt betroffen.
Und in jeder Fritz!OS-Version steckt (mindestens der Shell- und Lua-) Code für viele verschiedene Hardware-Versionen, der die Firmware nicht nur unnötig aufbläht, sondern auch eine Wartung unnötig erschwert, da man wesentlich schneller die Übersicht verliert. Ein Präprozessor, der die für die jeweilige Zielplattform benötigten Code-Teile auswählt und daraus eine genau passende Datei erstellt, ist kein Hexenwerk und das Prinzip seit vielen Jahrzehnten bekannt.

Ich gehöre i.d.R. nicht zu den AVM-"Bashern" ... aber wenn man sich die Entwicklungen der letzten Jahre so ansieht, dann sinkt bei mir die Zufriedenheit mit den Produkten und der Produktpolitik insgesamt rapide.

Wenn irgend ein anderer Anbieter die nackte Hardware in einer vergleichbaren Integrationsdichte als Basis für eine Open Source-Lösung anbieten würde, wäre diesem Hersteller sicherlich ein gewisses Stück des Kuchens (ich schätze mal so um die 5% des Marktes) bei den Anwendern sicher, die einerseits eine transparente Software (auch wenn Heartbleed eine Katastrophe war, ist mir eine solche aufgedeckte Lücke immer noch lieber als die diversen unentdeckten, verschwiegenen oder sogar absichtlichen Lücken in proprietärer Software) und andererseits aber auch eine flexible und vielseitige Lösung in einen einzelnen Gerät haben wollen.

Die eher geringe internationale Verbreitung der Fritz!Boxen (außerhalb des deutschsprachigen Raumes meines Wissens nur noch in Australien nennenswert) ist sicherlich nicht darauf zurückzuführen, daß kein Bedarf besteht oder "Made in Germany" auf einmal nicht mehr als Qualitätskriterium gilt. Aber auch ich traue inzwischen einer Firma, die plötzlich und unerwartet in ihrer Firmware die Sicherheit von HTTPS-Verbindungen quasi auf Null zurückfährt, nicht mehr wirklich über den Weg ... warum sollten internationale Anwender (bzw. Zugangsanbieter, denn die bringen in D die hohe Marktdurchdringung) das anders sehen ?

Wenn schon die internationale Nachfrage nach Cisco-Geräten (im Zusammenhang mit NSA-Manipulationen ?) sinkt ... warum sollten AVM und den Netzanbietern nicht auch von unseren Diensten entsprechende Auflagen gemacht worden sein ? Die seit Jahren versprochenen Sicherheitsoptionen bei der IP-Telefonie sehe ich jedenfalls in keiner offiziell erhältlichen Firmware und bei ständigen neuen Erfolgsmeldungen zur Umstellung von Anschlüssen auf NGN habe ich immer die steigende Anzahl von unverschlüsselten Telefonaten, für deren massenhafte Ausleitung und ungezielte Speicherung der Aufwand immer mehr sinkt, vor Augen. Wenn hier plötzlich verbreitet SRTP oder ZRTP zum Einsatz käme, wären sicherlich einige "Sicherheitsbeamte" verärgert ... aber die sind mir persönlich schnuppe.
 
Zuletzt bearbeitet:
Mit einer Umstellung von squashfs auf ubifs,
Von technologischen Dingen mal abgesehen: eine Stärke von Fritz!OS ist sicherlich die lange Entwicklungszeit, die man auch mit viel Erfahrung gleichsetzen kann (können sollte; 7390, 7490, 6.03 auf 6360 ("VPN vs Telefonie") werfen große Fragezeichen auf). Allerdings, daß /assis/internet_dsl.lua in der 6.04 für die Kabelbox 6360 drinsteckt, überraschte mich auch. Andererseits ist es sehr angenehm, daß meist nur durch's Branding die Funktion eingeschränkt wird; viele haben davon schon profitiert, der eigenen oder einer Zweitbox aus der Bucht mit einem Klick zu vollem Funktionsumfang zu verhelfen ...
Wenn man AVMs Fritz-FW/Fritz!OS mit Lösungen anderer Anbieter vergleicht, finde ich schon, daß da eine beachtliche Konsistenz in Leistungsumfang und Bedienkonzept existiert. Dinge, die ich bei ALLNET, EDIMAX oder TP-LINK jetzt so nicht unterschreiben würde.

Und ja, die "ewige" Weiternutzung "bewährter" Lösungen ebenet natürlich den Weg zu einer Anfälligkeit einer breiten Produktpalette, sollten Kernteile davon sich als "bewährt, aber scheiße" erweisen. Dennoch, ohne die Art und Weise, wie die Fritz-Firmware evolutionär entwickelt wird, hätte es von AVM kaum selbst für Uralt-Boxen gefixte Firmwares innerhalb eines Wochenendes gegeben. (Wie lange warten die XYZ-Router-Nutzer nun schon auf Updates gegen Hintertüren in ihrem Router?)

Den Markt für "modulare, routende Wollmilchsäue" sehe ich jenseits der Wirtschaftlichkeit. Schlußendlich kommen ja auch die Netzbetreiber dazu; warum dem Vernehmen nach bei enigen Kabel-Anbieter zusätzliches SIP in deren IAD-Fritzen gesperrt ist? Kann für mich mit der Quersubventionierung durch Telefongebühren zusammenhängen (DS-lite ... könnte natürlich ein technischer Grund sein). Jene Netzbetreiber werden aber auch Dein Paketsystem blocken (lassen). Unterschiedliche Architekturen machen es nicht einfacher, wobei Geld damit nicht zu holen ist. IMHO, YMMV.

Ich gehöre i.d.R. nicht zu den AVM-"Bashern" ... aber wenn man sich die Entwicklungen der letzten Jahre so ansieht, dann sinkt bei mir die Zufriedenheit mit den Produkten und der Produktpolitik insgesamt rapide.
Ich gehöre seit der stillen Abkündigung des Supports für die 7570 eher dazu; es hätte AVM nicht das Genick gebrochen, dieses ehemalige VDSL-Flagschiff parallel zu ihrem ehemaligen DSL-Flagschiff mit auf die Reise nach Version 5/6 zu nehmen. Und seit mit 5.50 meine 7360 plötzlich (das war ein verdammtes Minor-Upgrade!) zu meinen Firmware-4-Repeatern (u. a. 7570) die Verbindung verlor, ist meine Meinung über Fritz!OS gefestigt: Basteln vor Betriebssicherheit. Schade drum.

Die eher geringe internationale Verbreitung der Fritz!Boxen ..
In D dürfte die Erfahrung seitens AVM mit ISDN und die Verbreitung dieser Telefonie-Technik geholfen haben, ferner die Annex-B-Fixierung -- die im Ausland deutsche Boxen schlecht nutzbar machte. Ich hätte mir immer ein modulareres System gewünscht (mein Hausanschluß ist absichtlich im Keller, was soll ich dort mit einer 802.11ac-Basis?!), mit Summe der Komponenten = Summe des Einzelgerätes, aber gut. Zur Verbreitung in D trug natürlich auch der Deal mit 1&1 bei, sowie deren Politik, bei Vertragsverlängerung 'ne neue Box preisgünstig anzubieten; letzteres befüllt die Bucht und sorgt zu noch mehr Marktanteil. Und bislang war so eine FB ja auch unglaublich praktisch, ein Gerät, was Netzabschluß, WLAN-Router, Telefonanlage, Anrufbeantworter, DECT-Basis und ggf. noch Switch ist ... Der Trend zur Homeautomation ist da und den wird man, denke, hoffe!, ich, auch nicht mehr aufhalten -- klar, daß AVM da mit seiner Erfahrung u. a. im DECT-Bereich mitmischen will.

Wobei ich -- und hier wird's dann wieder on-topic -- noch immer schockiert bin, daß meine olle Gigaset-Basis problemlos aus dem EG bis ins OG und bis zur Hauptstraße DECT liefert, die 7270v3 an gleicher Stelle aber nicht einmal mehr das OG für Telefonie ausreichend abdeckt. Auch wenn ich aus verschiedenen Gründen gerne auf FritzBox-DECT gehen würde: wenn ich dann nur noch in Sichtweite der FritzBox "mobil" sein kann, läuft was verkehrt. Und hier ist leider mit der neuen Beta nichts besser geworden bei mir. Ich habe zwei 7270v3 im EG, die erste an einer Hausecke ist Basis, eine zweite, mehr in der MItte des Hauses platziert, ist DECT-Repeater der ersten. Eine dritte 7270v3 im OG habe ich ebenfalls als Repeater angeschlossen, die hat aber im OG keine Verbindung mehr zur Basis (Info blinkt). ... Auf den 7270v3 im EG ist FRITZ!OS 06.04-27949 BETA installiert, bei DECT spüre ich keine Verbesserung -- Mobilteil M2 sagt 1 Balken zur Basis, 3 (von 5) Balken zum Repeater im EG. Testanruf knarzt und zirrpt, analoger Funk ist Gold dagegen :(


Ach so, "Sicherheit von HTTPS-Verbindungen quasi auf Null zurückfährt", hu? Hintergrund-Link für diese Aussage?
 
Ach so, "Sicherheit von HTTPS-Verbindungen quasi auf Null zurückfährt", hu? Hintergrund-Link für diese Aussage?
Seit Herbst 2013 hat AVM für neue Firmware-Versionen die möglichen HTTPS-Verschlüsselungen konsequent auf RC4-MD5/RC4-SHA kastriert. Zur Sicherheit der verwendbaren Verfahren empfehle ich eine Suchmaschine.

Dafür feiert man bei AVM jetzt für die 7490:
Code:
NEU - Unterstützung von TLS 1.2 (SSL mit AES) für die https-Fernwartung der FRITZ!Box

Allerdings vergißt man dabei glatt zu erwähnen, daß die dort wieder verwendbaren zusätzlichen Verfahren AES128-SHA und AES256-SHA auch alles andere als optimal sind, weil sie ohne "Perfect Forward Secrecy" arbeiten. Wenn also irgendwie der private Schlüssel der Fritz!Box bekannt wird (der steht - mit boxabhängiger Verschlüsselung - in der Datei /var/flash/websrv_ssl_key.pem), kann man vorher aufgezeichnete Sitzungen nachträglich decodieren.
Edit 28.05.2014:
Anders als ursprünglich von mir behauptet, unterstützt die Laborversion für 7390/7490 sehr wohl PFS, allerdings ausschließlich ECDHE-basierte Verfahren.

Ich verstehe ja, daß man bei einem Webserver, der unter hoher Last läuft, auf die Runtime-Effizienz der Verschlüsselung achten muß. Auf meiner Fritz!Box ist mir das aber ziemlich egal, denn die soll ohnehin nicht hunderte parallele Verbindungen verarbeiten können. Wenn AVM irgendwie Angst hat, daß man bei sicherer Verschlüsselung das externe Webinterface als zu langsam beschimpfen könnte, sollten sie wenigstens dem Besitzer die Wahl zwischen Geschwindigkeit und Sicherheit überlassen.
 
Zuletzt bearbeitet:
Ich habe mit dieser neuen Firmware Probleme über VOIP telefonieren/Anrufen.
Man bekommt häufig SIP 701 Fehler beim anrufen.

Ich war ziemlich zufrieden mit der 7270v3 27861
 
Zuletzt bearbeitet:
Erste komplette WLAN-Abstürz. Leider nichts in den Logs..

Habe ein 7270v3 mit dieser Labor-Version in 2.ter Reihe als weiteren Wlan-AP in der Whg meiner Tochter. Per Lan versorgt sie lokale Klienten und ist mit dem LAN-Port1 im selben LAN mit dem "Uplink" 7270v2 (keine Labor) in meiner Whg verbunden. Beide funken dieselbe SSID, die v3 auf Kanal 13 und die v2 auf Kanal 1 (und ein "DD-WRTeter" weiterer TP-Link wieder auf Kanal 13).

Nun habe ich meiner Tochter von ein paar Tagen einen Raspberry Pi mit OpenELEC XBMC zum Fernsehgucken (htsp: ) aufgesetzt, der mit einen 802.11g USB-Stick arbeitet und sich in an der v3 einbucht. Der Videostream kommt aus meiner Wgh von einem SheevaPlug auf dem ein TVHeadend läuft.

Ich hatte nun mehrfach, dass die v3 morgens nicht mehr "ansprechbar" war und nur ein Power-Off/On sie wiederbelebte. Das ganze passiert immer vor Mitternacht, da ich dann auch keine Push-Mail der Kiste erhalte. Leider keine Logs, aber ich habe die Vermutung, dass das (intensive) Streamen der Kiste zu schaffen macht!?

Ich habe noch einen 802.11n-Stick, den ich alternativ im Pi ausprobiere.
 
Zuletzt bearbeitet:
ist eher unwahrscheinlich, da die 7270 schon längst EOS ist.
»Längst«, naja, seit 31.12.2013 lt, AVMs Liste. Slightly off topic: warum findet sich die 7240 nicht in der Liste, wird die noch weiter unterstützt, während AVM die große Schwester auf's Altenteil schiebt, oder hat das wieder was mit »Providergerät« zu tun?

Habe ein 7270v3 mit dieser Labor-Version in 2.ter Reihe [...] Der Videostream kommt aus meiner Wgh von einem SheevaPlug auf dem ein TVHeadend läuft. [...] Ich hatte nun mehrfach, dass die v3 morgens nicht mehr "ansprechbar" war und nur ein Power-Off/On sie wiederbelebte.
Also ich hatte das "Ethernet tot"-Problem an einer meiner 7270v3 mit der vorigen Labor; mit der aktuellen, toi, toi, toi, noch nicht wieder. Andere berichten auch über sporadische bis häufige Ethernet-Ausfälle (ob Zugang per WLAN dann noch geht, keine Ahnung; bei mir steht der DHCP-Server im LAN ...).

Gretchenfrage: warum die Beta auf der 7270v3, welches Feature brauchtst Du auf dem AP, der die 7270v3 (auch) bei Dir ist? Lies: klatsch doch wieder die 05.54 drauf und freu Dich über eine (hoffentlich) stabile Box. Bevor ich bei einer 7270v3 über Belastung durch Videostreaming nachdenken würde (selbst ARD HD per DVB-S2 sind unter 15 MBit/sec, ARD/ZDF SD irgendwas bei 4 MBit/sec IIRC), würde ich die Ausfälle eher auf Probleme der 6.0x-Labor mit der einen oder anderen Hardware schieben. FTR, ich hatte mal mehrere Monate zwei auf 7270v2-UI gefritzte W503V als »WLAN-Kabel« durch's Wohnzimmer »gespannt«, an einem Ende der Laptop mit vdr-sxfe-Frontend, am anderen Ende ein VDR, dessen Platte per NFS auf einem zweiten, mit dem Laptop am Switch hängenden VDR gemountet war. Ich habe etliche hundert GB an Daten über den ca. 80 MBit/sec netto liefernden Link kopiert, ohne Probleme (außer, etwas stand im Weg). (Mittlerweile liegt da aber doch ein GBit-Kabel ;))
 
Zuletzt bearbeitet:
ob Zugang per WLAN dann noch geht, keine Ahnung; bei mir steht der DHCP-Server im LAN
Bei mir auch, aber gute Idee. Ich könnte einen Wlan-Klienten ja mal eine feste IP verpassen und schauen, ob denn die IP der FB weiterhin erreichbar ist ...

warum die Beta auf der 7270v3 ...
re 05.54 ja "hoffentlich". Nein, es gibt keinen wirklichen "Feature"-Grund, der die Nutzung der Labor-Version "rechtfertigt". Aber man ist eben doch gern "am Puls der Zeit" und da bot sich bis dato die nicht ganz so wichtige v3 an. Da ich auf der v2 per debug.cfg einen OpenVPN von Stick nachlade und es die Methode z.Z. mit dieser Labor nicht mehr gibt, könnte dies eh das KO-Kriterium sein (zumindest für die v2 am DSL-Anschluss).

[VERSCHWÖRUNGSTHEORIE]Für die 7270er wird es eh keine Finalversion mehr geben. AVM nutzt nur noch die breite Installationsbasis und hohe Anzahl an Testwilligen für ihre Debugging-Zwecke ;-)[/VERSCHWÖRUNGSTHEORIE]
 
Hat noch jemand bei sich das Phänomen feststellen können, daß diese Labor-Version beim Versuch, eine "fremde" Firmware zu flashen

1. nicht mehr die übliche Warnung "Diese Firmware wurde von AVM nicht freigegeben ..." ausgibt und dann leider

2. auch kein sinnvolles Update ausführt, d.h. es sieht erst einmal alles gut aus beim Update (LEDs blinken wie erwartet), doch die Box startet nach dem Update nicht mehr richtig.

Das dabei verwendete Image ist aber in Ordnung ... wenn ich es direkt von der letzten Release-Version (dann inkl. Warnung wie unter Ziffer 1 oben) flashe, läuft es ohne Probleme.

Den Versuch, eine von AVM-signierte Version von dieser Labor aus zu flashen, kann ich ja nicht durchführen, da die Laborversion ohne Recover kein Downgrade zulassen dürfte. Oder ist das inzwischen anders ?
 
Zuletzt bearbeitet:
Ich habe noch einen 802.11n-Stick, den ich alternativ im Pi ausprobiere.

Nein, wie mir berichtet wurde, ist sie wieder "abgeschmiert". Ich konnte aber nicht testen, ob es ein "LAN"-, oder "WLAN"-Problem ist, da bereits ein Neustart mit Power-Off/On gemacht wurde. Push-Mail kam normal:

FRITZ!Box Einstellungsübersicht vom 28.05.2014 00:03 Uhr
Produktname FRITZ!Box Fon WLAN 7270 v3
Firmware FRITZ!OS 74.06.04-27949
WLAN aktiv, WPA + WPA2
Rufumleitung nicht aktiv
Anrufe sperren nicht aktiv
Nachtschaltung nicht aktiv
Fernzugriff über HTTPS aktiv: https://194.x.y.z
Energieverbrauch 45 %
Letzter Neustart 27.05.2014 21:01 Uhr

Ich wollte mich gerade remote verbinden, hatte aus "Versehen" auf den obigen HTTPS-Eintrag geklickt, statt "normal" per HTTP (meine OpenVPN-Verbindung ins lokale Netz steht via der v2).
Das scheint sie aber auch nicht zu mögen, denn damit habe ich sie anscheinend wieder "abgeschossen".
 
@olivetti: Ich hatte jetzt angenommen, dass ein Verweis auf das ruKernelTool kommt, aber doch nicht auf ein Downgrade Script von 2005. :?
 
Danke, aber die Frage zielte mehr in die Richtung, ob AVM da auch etwas geändert hat und ob jemand etwas darüber sagen könnte.

Haben sie aber nicht ... die letzte verfügbare Release-Version für die 7270v3 testet in 'install' immer noch brav die Zahl zwischen den Punkten in der Versionsnummer und mault, wenn die "neue" kleiner ist als die "alte". Allerdings braucht es kein Recover, es wird aber auf Werkseinstellungen zurückgesetzt beim Flashen einer vorhergehenden Version.
Code:
    if [ "$middle_newFWver" -lt "$middle_currFWver" ] ; then
        echo "warning: Firmware downgrade detected"
        echo "set INFO led to off (modul=7, state=1)"
        /bin/update_led_off
        # behaviour for devices which basically are downgradable
        exit $INSTALL_DOWNGRADE_NEEDED
    else
        echo "DEBUG: $middle_newFWver >= $middle_currFWver"
    fi
    if [ "$middle_newFWver" -eq "$middle_currFWver" ] ; then
        if [ "$minor_newFWver" -lt "$minor_currFWver" ] ; then
                echo "warning: Firmware downgrade detected"
                echo "set INFO led to off (modul=7, state=1)"
                /bin/update_led_off
                # behaviour for devices which basically are downgradable
                exit $INSTALL_DOWNGRADE_NEEDED
        else
            echo "DEBUG: $minor_newFWver >= $minor_currFWver"
        fi
    else
        echo "DEBUG: $middle_newFWver > $middle_currFWver"
    fi
    echo "Accept Firmware Version: xx.${newFWver}"

Das könnte man mit einer Modifikation der /etc/version zwar tatsächlich abstellen ... aber ich wollte ja ursprünglich nur wissen, ob AVM da an der Vorgehensweise etwas geändert hat. Und KunterBunter hat natürlich auch recht ... wenn ich es ausführen will, kann ich auch gleich das ruKernelTool nehmen, wenn ich das zu flashende Image habe. Solange man dort nicht mtd3/mtd4 löschen läßt, kann man sogar das Factory-Reset umgehen ...

Auch bei mehrmaliger Wiederholung (allerdings nur 2x probiert, bevor jemand mit dem Sinnspruch von Einstein kommt :)) kann ich wirklich reproduzierbar in die Version vom April und in diese ein unsigniertes Image zum Flashen laden, ohne daß der firmwarecfg sich darüber beschwert. Allerdings startet das frisch geflashte Image dann nicht richtig. Flashe ich dasselbe Image von der Release-Version (also der mit dem Fix vom Februar) aus, funktioniert das "custom image", aber es kommt die Warnung von firmwarecfg. Dabei habe ich natürlich dieses Labor-Image auch immer neu geflasht ... die Box startete ja nach dem Versuch mit dem eigenen Image nicht mehr und mußte mit ruKT wiederbelebt werden (da immer auf die Release aus dem Februar).

Seltsam ... aber wahrscheinlich kommt ohnehin bald die nächste Version, wenn es denn noch eine geben sollte ... dann sehe ich mir das noch einmal an.

Ich glaube jedenfalls nun doch nicht mehr daran, daß AVM sich künftig *nicht* mehr an unsignierter Firmware stören wird. Für mich sieht das eher nach einem etwas mißglückten Versuch aus, die Installation unsignierter Firmware über das GUI zu unterbinden.

Ich hoffe aber, ich irre mich ... denn dem "Low-Level"-Flashen per FTP beim PowerOn wird AVM ohne mtd2-Update nicht entgegenwirken können. Aber für den Fall der Fälle habe ich mir schon mal eine Kopie des derzeitigen Urladers beiseite gelegt.
 
Seltsam ... aber wahrscheinlich kommt ohnehin bald die nächste Version, wenn es denn noch eine geben sollte ... dann sehe ich mir das noch einmal an.

Auch seltsam: als ich das letzte mal nachgeschaut habe, war meine Box (ArtNo 20002456) auf der EOS Seite aufgeführt (EOS: 01.05.2014), nun ist sie es nicht mehr.
Daraus schließe ich: es gibt noch Support.

vg SC
 
Status
Für weitere Antworten geschlossen.
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.