- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Schaut man sich die Firmware für die 7580 beginnend mit der Version 06.83 etwas genauer an, findet man dort eine Datei "/etc/init.d/rc.errata.sh", die genau für alle 7580 mit "HWSubRevision 2" (die erste Hürde) und einer Seriennummer "Hxxx" bzw. einer Seriennummer < "J115" (also vor dem 10.03.2017 hergestellt - das ist die zweite Hürde) eine zusätzliche Environment-Variable mit dem Namen "CONFIG_ERRATUM_33654" und dem Wert "1" setzt (beim Start der Firmware).
Die einzige Stelle in der Firmware, (die ich jedenfalls gefunden habe und) wo eine Variable "CONFIG_ERRATUM_" als Text vorkommt, ist die Bibliothek "libwland_hal.so". Diese ist dafür zuständig, aus der "wlan.cfg" und der tatsächlich vorhandenen Hardware (in "/etc/default/$OEM" gibt es einige dazugehörende Dateien) eine halbwegs einheitliche Konfigurationsdatei (in "/var/tmp") zu erstellen, mit der dann das WLAN wirklich arbeiten kann.
Das ist das erste Mal, daß ich so etwas bei der AVM-Firmware sehe ... da stellt sich nun natürlich die Frage, was in der Produktion am 10.03.2017 geändert wurde und nicht parallel zu einer anderen "HWSubrevision" geführt hat, denn es geht hier ja nur um die "2". Die anderen Boxen lassen sich sicherlich schon anhand der "HWSubRevision" ausschließen, wobei diese zusätzliche CONFIG-Variable wohl ohnehin nur verwendet wird, um beim Laden des Kernel-Moduls "aae.ko" (Beschreibung: AVM extensions for Atheros MadWifi driver) den Parameter "errata=" auf die Liste der Nummern hinter diesen "CONFIG_ERRATUM_nnnnn=1"-Einträgen im Environment zu setzen.
Bei der Auswertung dieses Parameters im erwähnten Kernel-Modul finden sich dann in der Nähe der Protokollierung dieses Parameters auch wieder Referenzen auf "HWRevision" und "HWSubRevision":
Bleibt für mich die Frage offen, was nun diesen Unterschied ausmacht ... eine denkbare Erklärung wäre eine (stille) Änderung am WLAN-Chip durch dessen Hersteller, die erst später kommuniziert wurde und nun auch AVM zu einer nachträglichen Reaktion zwang ... dabei sollte vielleicht nicht unerwähnt bleiben, daß dieser "errata"-Parameter für das Kernel-Modul auch erst mit der 06.83 neu eingeführt wurde - das ist also keinesfalls eine schon länger existierende Vorsichtsmaßnahme, mit der man auf solche Probleme reagieren kann.
Am Beginn dieses Jahres hatte sich ja Google's "Project Zero" etwas genauer mit den WLAN-Chips z.B. in diversen Smartphones befaßt und dabei offenbar Fehler gefunden, die dann von den Herstellern beseitigt und ab April auch kommuniziert wurden: https://googleprojectzero.blogspot.de/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
Da geht es zwar um Broadcom-Chips (und die FRITZ!Boxen arbeiten mit Atheros-WiSoCs), aber das mündete dann in die BroadPwn-Story, bei der sich passende ungepatchte Smartphones ohne Nutzerinteraktion über das WLAN übernehmen lassen.
Aber das muß ja nicht automatisch heißen, daß Atheros-SoCs nicht auch von Problemen betroffen waren ... auch wenn die vielleicht nicht so gravierend ausgefallen sind.
Eine (denkbare?) Möglichkeit wäre daher in meinen Augen, daß Atheros etwas geändert hat und AVM nicht mehr dazu kam, das rechtzeitig mit einer anderen "HWSubRevision" zu verknüpfen (die auch zuvor schon im "aae.ko" ausgewertet wurde), so daß man diesen neuen "errata"-Parameter bei den eigenen Treibern einbauen mußte und das auch noch irgendwie "von außen" steuern muß, was da konkret enthalten ist.
Die viel interessantere Frage ist es aber für mich, was dieser Parameter am Ende nun bewirken mag ... auch hier gibt es ja mehrere denkbare Ansätze.
Entweder er sorgt dafür, daß tatsächlich ein "Erratum" umgangen wird (der Begriff wird ja auch für Microcode-Fehler und/oder deren Dokumentation verwendet) und am Ende kommt tatsächlich dieselbe Funktionalität dabei heraus oder er bewirkt (ggf. auch erst nach der Weitergabe an andere Module, gerne auch welche direkt von Atheros), daß irgendeine Funktionalität gar nicht erst aktiviert wird, weil sie ohnehin (hardwarebedingt und damit nicht durch Firmware-Udpate für das WiSoC zu beheben) nicht benutzbar ist.
Ich habe jedenfalls bei einer Internetsuche mit der Nummer "33654" nichts gefunden, was irgendwie auf einen "offiziellen" Fehler von Atheros schließen ließe ... das macht es dann eigentlich wieder unwahrscheinlich, daß tatsächlich etwas bei diesem Chip-Hersteller passiert ist.
Dann bliebe wieder nur AVM und deren Fertiger als der "Verursacher" dieser - ja wohl doch einschneidenden - Veränderung übrig und da fehlt mir einfach die Phantasie, warum es am 10.03.2017 diese Zäsur gab und die dann am Ende sogar dazu führte, daß man am "aae.ko" noch herumdoktern mußte/wollte.
Angesichts der bei der 7580 auch längerfristig berichteten Probleme mit dem WLAN nach der Auslieferung der ersten Geräte ist das dann aber auch wieder nicht ganz so unerklärlich (auch wenn das natürlich alles Spekulation ist, weil man bei AVM dazu auch nichts wirklich Gehaltvolles an Informationen findet) - da wäre dann höchstens die doch recht lange Dauer bemerkenswert, wenn Boxen mit "Hxxx" auch betroffen sind.
Das sind dann mal mindestens 11 Wochen, wenn nicht noch länger, denn die Dauer von "HWSubRevision 2" in 2016 ist ja unklar.
Andererseits ... meine 7580 hat "J071" und trotzdem die "HWSubRevision 1" - ist also nur knapp fünf Wochen vor dem "Stichtag" für die "rc.errata.sh" produziert.
Vielleicht ist ja die Einbeziehung von "Hxxx"-Boxen auch eine reine Vorsichtsmaßnahme, weil diese alle noch die "HWSubRevision 1" hatten.
Das ist also (zumindest in meinen Augen) ganz schön mysteriös, was da am 10.03.2017 wohl geschehen sein mag ... vielleicht hat ja jemand genauere Informationen oder auch andere Ideen, welche wundersamen Änderungen da nun stattgefunden haben (es wird ja nicht nur irgendeine Änderung am PCB sein, die seit diesem Tag nun dazu führt, daß irgendein Teil des WLAN bei der 7580 endlich so arbeiten kann, wie es sein soll).
Auf der anderen Seite hatten wir bei der 6590 (iirc) ja auch so eine "Schote" ... da stimmte dann die Zuordnung der "FONx"-Anschlüsse in der Firmware nicht mit dem überein, was auf das Gehäuse geprägt war und - nach dem, was man hier im IPPF lesen konnte - AVM plante dann angeblich sogar, anstelle der Firmware die Gehäuse zu ändern.
Da muß man sich dann auch über solche "Kopfstände" wie eine Sonderbehandlung vor/nach einem bestimmten "Stichtag" vielleicht nicht wirklich wundern, auch wenn hier ggf. Hardware-Probleme durch Software-Änderungen behoben werden ... also genau die Gegenrichtung zum Ändern der Gehäuse bei der 6590 - ist da eigentlich irgendetwas geschehen in der Zwischenzeit?
Jedenfalls kommt man bei der Firmware kaum noch aus dem Staunen heraus ...
Die einzige Stelle in der Firmware, (die ich jedenfalls gefunden habe und) wo eine Variable "CONFIG_ERRATUM_" als Text vorkommt, ist die Bibliothek "libwland_hal.so". Diese ist dafür zuständig, aus der "wlan.cfg" und der tatsächlich vorhandenen Hardware (in "/etc/default/$OEM" gibt es einige dazugehörende Dateien) eine halbwegs einheitliche Konfigurationsdatei (in "/var/tmp") zu erstellen, mit der dann das WLAN wirklich arbeiten kann.
Das ist das erste Mal, daß ich so etwas bei der AVM-Firmware sehe ... da stellt sich nun natürlich die Frage, was in der Produktion am 10.03.2017 geändert wurde und nicht parallel zu einer anderen "HWSubrevision" geführt hat, denn es geht hier ja nur um die "2". Die anderen Boxen lassen sich sicherlich schon anhand der "HWSubRevision" ausschließen, wobei diese zusätzliche CONFIG-Variable wohl ohnehin nur verwendet wird, um beim Laden des Kernel-Moduls "aae.ko" (Beschreibung: AVM extensions for Atheros MadWifi driver) den Parameter "errata=" auf die Liste der Nummern hinter diesen "CONFIG_ERRATUM_nnnnn=1"-Einträgen im Environment zu setzen.
Bei der Auswertung dieses Parameters im erwähnten Kernel-Modul finden sich dann in der Nähe der Protokollierung dieses Parameters auch wieder Referenzen auf "HWRevision" und "HWSubRevision":
Code:
6[wlan_config] Prodtest is set. Using empty config!
6[wlan_config] hwrev=%u hwsubrev=%u maca=%02x:%02x:%02x:%02x:%02x:%02x
6[wlan_config] errata list=%s
HWRevision
HWSubRevision
macaBleibt für mich die Frage offen, was nun diesen Unterschied ausmacht ... eine denkbare Erklärung wäre eine (stille) Änderung am WLAN-Chip durch dessen Hersteller, die erst später kommuniziert wurde und nun auch AVM zu einer nachträglichen Reaktion zwang ... dabei sollte vielleicht nicht unerwähnt bleiben, daß dieser "errata"-Parameter für das Kernel-Modul auch erst mit der 06.83 neu eingeführt wurde - das ist also keinesfalls eine schon länger existierende Vorsichtsmaßnahme, mit der man auf solche Probleme reagieren kann.
Am Beginn dieses Jahres hatte sich ja Google's "Project Zero" etwas genauer mit den WLAN-Chips z.B. in diversen Smartphones befaßt und dabei offenbar Fehler gefunden, die dann von den Herstellern beseitigt und ab April auch kommuniziert wurden: https://googleprojectzero.blogspot.de/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
Da geht es zwar um Broadcom-Chips (und die FRITZ!Boxen arbeiten mit Atheros-WiSoCs), aber das mündete dann in die BroadPwn-Story, bei der sich passende ungepatchte Smartphones ohne Nutzerinteraktion über das WLAN übernehmen lassen.
Aber das muß ja nicht automatisch heißen, daß Atheros-SoCs nicht auch von Problemen betroffen waren ... auch wenn die vielleicht nicht so gravierend ausgefallen sind.
Eine (denkbare?) Möglichkeit wäre daher in meinen Augen, daß Atheros etwas geändert hat und AVM nicht mehr dazu kam, das rechtzeitig mit einer anderen "HWSubRevision" zu verknüpfen (die auch zuvor schon im "aae.ko" ausgewertet wurde), so daß man diesen neuen "errata"-Parameter bei den eigenen Treibern einbauen mußte und das auch noch irgendwie "von außen" steuern muß, was da konkret enthalten ist.
Die viel interessantere Frage ist es aber für mich, was dieser Parameter am Ende nun bewirken mag ... auch hier gibt es ja mehrere denkbare Ansätze.
Entweder er sorgt dafür, daß tatsächlich ein "Erratum" umgangen wird (der Begriff wird ja auch für Microcode-Fehler und/oder deren Dokumentation verwendet) und am Ende kommt tatsächlich dieselbe Funktionalität dabei heraus oder er bewirkt (ggf. auch erst nach der Weitergabe an andere Module, gerne auch welche direkt von Atheros), daß irgendeine Funktionalität gar nicht erst aktiviert wird, weil sie ohnehin (hardwarebedingt und damit nicht durch Firmware-Udpate für das WiSoC zu beheben) nicht benutzbar ist.
Ich habe jedenfalls bei einer Internetsuche mit der Nummer "33654" nichts gefunden, was irgendwie auf einen "offiziellen" Fehler von Atheros schließen ließe ... das macht es dann eigentlich wieder unwahrscheinlich, daß tatsächlich etwas bei diesem Chip-Hersteller passiert ist.
Dann bliebe wieder nur AVM und deren Fertiger als der "Verursacher" dieser - ja wohl doch einschneidenden - Veränderung übrig und da fehlt mir einfach die Phantasie, warum es am 10.03.2017 diese Zäsur gab und die dann am Ende sogar dazu führte, daß man am "aae.ko" noch herumdoktern mußte/wollte.
Angesichts der bei der 7580 auch längerfristig berichteten Probleme mit dem WLAN nach der Auslieferung der ersten Geräte ist das dann aber auch wieder nicht ganz so unerklärlich (auch wenn das natürlich alles Spekulation ist, weil man bei AVM dazu auch nichts wirklich Gehaltvolles an Informationen findet) - da wäre dann höchstens die doch recht lange Dauer bemerkenswert, wenn Boxen mit "Hxxx" auch betroffen sind.
Das sind dann mal mindestens 11 Wochen, wenn nicht noch länger, denn die Dauer von "HWSubRevision 2" in 2016 ist ja unklar.
Andererseits ... meine 7580 hat "J071" und trotzdem die "HWSubRevision 1" - ist also nur knapp fünf Wochen vor dem "Stichtag" für die "rc.errata.sh" produziert.
Vielleicht ist ja die Einbeziehung von "Hxxx"-Boxen auch eine reine Vorsichtsmaßnahme, weil diese alle noch die "HWSubRevision 1" hatten.
Das ist also (zumindest in meinen Augen) ganz schön mysteriös, was da am 10.03.2017 wohl geschehen sein mag ... vielleicht hat ja jemand genauere Informationen oder auch andere Ideen, welche wundersamen Änderungen da nun stattgefunden haben (es wird ja nicht nur irgendeine Änderung am PCB sein, die seit diesem Tag nun dazu führt, daß irgendein Teil des WLAN bei der 7580 endlich so arbeiten kann, wie es sein soll).
Auf der anderen Seite hatten wir bei der 6590 (iirc) ja auch so eine "Schote" ... da stimmte dann die Zuordnung der "FONx"-Anschlüsse in der Firmware nicht mit dem überein, was auf das Gehäuse geprägt war und - nach dem, was man hier im IPPF lesen konnte - AVM plante dann angeblich sogar, anstelle der Firmware die Gehäuse zu ändern.
Da muß man sich dann auch über solche "Kopfstände" wie eine Sonderbehandlung vor/nach einem bestimmten "Stichtag" vielleicht nicht wirklich wundern, auch wenn hier ggf. Hardware-Probleme durch Software-Änderungen behoben werden ... also genau die Gegenrichtung zum Ändern der Gehäuse bei der 6590 - ist da eigentlich irgendetwas geschehen in der Zwischenzeit?
Jedenfalls kommt man bei der Firmware kaum noch aus dem Staunen heraus ...
