[Problem] 7490 - keine Supportdaten - Download hängt

[morenoralfo]

Ich habe inzwischen im Zusammenhang mit einer laufenden Supportanfrage
ein Recovery einer FB 7490 international (OS 6.83) durchgeführt.

Leider kann ich noch immer keine aussagekräftigen Supportdaten erhalten.
Nur mit der jungfräulichen Box nach Werksreset/Recovery gelingt es mir Supportdaten zu generieren.

Sobald ich auch nur Teile der Einstellungen
meiner FB7390 6.20 zurückspiele kann ich keine
Supportdaten mehr erstellen.

Der Download hängt dan immer zwischen 141 kB und 177 kB
und kommt an kein Ende. (mit diversen Endgeräten und Browsern probiert)
Durch Kopieren der *.part Dateien und Umbennen habe ich inzwischen lesbare
Dateien erhalten welche natürlich nur einen Bruchteil der gewünschten
Supportdaten enthalten. Der Download läuft bis maximaal
##### BEGIN SECTION System_Status System status
....
DSL Line Test
-------------

Calibrate Echo :

Ich habe aber kein DSL konfiguriert, sondern hänge hinter einem Genexis Mediakonverter (ftth)
(Ich bin sicher kein Einzelfall: 7490-keine-support-daten)

Jemand hier mit einer brauchbaren Idee wie ich die Neugier des Supports doch noch befriedigen könnte?
(Ausser durch alles händisch zu konfigurieren - und dann doch keine Supportdaten zu erhalten.

 

[stoney]

Kein Einzelfall?

Auf diesen Thread wurde nicht geantwortet. Etwas mehr überzeugen müsstest Du dann schon. Außerdem besteht dort das Problem i.V.m VPN (hab es nur überflogen)

Was passiert denn wenn die Sicherung wieder auf eine 7390 kommt ?

Warum auch eine Sicherung von 6.20?

 

[morenoralfo]

1) Mit mir sind es schon wenigstens zwei (mir) bekannte Fälle wenn ich richtig zähle.

2) Op das Supportdatenproblem mit dem VPN zusammenhängt weiss ich nicht und Du auch nicht.
Ich habe zur Sicherheit bei mir keine Netzwerkdaten/Freigaben/VPN Konfigurationsdaten zurückgespielt.

2) Warum sollte ich die Sicherung wieder auf meine FB 7390 zurückspielen?
Was wäre damit bewiesen wenn es danach auch hängt bzw. nicht hängt?
Und vor allen Dingen was könnte ich damit produktives anfangen?

3) Wenn ich meine aktuellen Probleme mit der 6.83 int. und meiner Konfiguration auf der 7490
betrachte spüre ich wenig Verlangen um nach einem Update ähnliche Neuigkeiten auch auf der 7390 zu erleben.

Vielleicht warte ich noch einige Wochen? auf das nächste Produktionsrelease der internationalen Version?
Oder ich mache aus der internationalen eine deutsche Version? (meine FB 7390 ist übrigens eine deutsche)
Man - das ganze hat mich inzwischen schon einiges an Zeit gekostet.

 

[stoney]

Vieleicht liegts ja daran das eine deutsche Sicherung auf eine intern. Box soll.

Die 7390 hat ebenso die 6.83 und ist zum produktiv Einsatz noch problemlos nutzbar.

Vll findest Du hier Nr. 3 und dir kann geholfen werden (ernst gemeint)

 

[morenoralfo]

@stoney0815 Deinen letzten Satz kann ich leider nicht entziffern, was meinst du mit "VII" und "Nr. 3"?

Der Gedanke das die deutsche und internationale Konfiguration irgendwie nicht kompatibel sein könnten,
dieser Gedanke kam auch bei mir auf.

Deshalb auch die Idee um die Version umzuflashen (ist in Arbeit),
auch um bei Gelegenheit die ein oder andere Laborversion in Zukunft zu checken.

Ich fürchte das die Version 6.83 auf meiner deutschen FB 7390 mit meiner heutigen Konfiguration,
wenn ich so nach meinen bisherigen Erfahrungen mit der 7490 sehe, auch nicht der Knaller sein wird.
Eigentlich wollte ich die FB 7390 nach 7 Jahren Dienst als Router in Pension schicken.

Einige neue Features der 6.83 sind ja ganz nett, aber wenn (dadurch?) andere Dinge nicht mehr
oder weniger gut funktionieren?

 

[stoney]

vll = vieleicht

Nr. 3 soll heißen - einen dritten Leidensgenossen mit dem selben Problem

Deshalb auch die Idee um die Version umzuflashen (ist in Arbeit),

Ich würde vorher trotzdem den Umweg über die 7390 nehmen - das ist mit maximal 1h Zeit verbunden, wenn man zB bei der 6.20 mit dem Wiederherstellen beginnt, dann vll. über die 6.30, 6.51 dann die 6.83, dann kannst Du zumindest schon mal den "großen" Sprung zwischen 6.20 und 6.83 ausschließen - dann doch eher de-int Problem.

Ich fürchte das die Version 6.83 auf meiner deutschen FB 7390 mit meiner heutigen Konfiguration,
wenn ich so nach meinen bisherigen Erfahrungen mit der 7490 sehe, auch nicht der Knaller sein wird.

Bitte erläutere.

Einige neue Features der 6.83 sind ja ganz nett, aber wenn (dadurch?) andere Dinge nicht mehr
oder weniger gut funktionieren?

Bitte zähle diese auf. Es gibt für vieles einen Workaround.

Außerdem geht es ja teilweise um Sicherheitsupdates - klar nicht schön wenn neue Funktionen dazu kommen, weshalb dann "alte" Sachen nicht mehr oder nur anders funktionieren.

Da fällt mir noch ein - ein "Downgrade" der 7490 auf 6.20 wäre auch noch eine Möglichkeit - falls kein Image oder Recovery vorhanden -> hier nachfragen - Suche Firmware & Recover-Images

 

[morenoralfo]

Bitte erläutere.

Bitte zähle diese auf. Es gibt für vieles einen Workaround.

Ich habe die Box erst seit 10 Tagen probeweise in Betrieb gehabt.

1) In meiner Supportanfrage und meinem anderen Beitrag in diesem Forum
thematisiere ich mein Problem mit den MyFritz Freigaben,
welche nicht mehr (so) richtig angelegt werden.
(Ich werde vll demnächst relevante Screenshots zur Illustration hinzufügen
und natürlich auch an AVM schicken.)

2) Weiterhin haben meine Mitbewohner und ich mit der FB7490 int 6.83 (niemals mit der FB 7390 6.20)
mehr oder weniger regelmässig hickups und Aussetzer beim Laden van Websites beobachtet
(auch Google war darunter) nach dem zweiten oder dritten Anlauf/Klick geht's es dann.




Ab Version 6.60 - Zitat: "Internet: Verbesserung - schneller Surfen durch optimierte Behandlung von DNS-Anfragen"
Bei meinem Anbieter? (Telfort = KPN) scheinbar eher nicht, auch alternative DNS-server helfen nicht.
(Hierfür müsste ich aber warscheinlich mal wieder wireshark und die packetcapture bemühen und beide Boxen miteinander vergleichen)

3) Ein weiteres Problem mit dem nicht vernünftig scrollbaren WEBGUI auf Androidgeräten
im Querformat (Responsive Design?) wurde bereits bestätigt und durch jemand
anderen hier im Forum an AVM gemeldet.

4) Und das Problem mit den Supportdaten.

 

[koyaanisqatsi]

Moin

Die 6.83 (6.88 Mesh Labor/Beta auch noch) hat Probleme mit Dual Stack (IPv6 & IPv4) Anschlüssen.
Teste: Probehalber mal IPv6 deaktivieren

 

[morenoralfo]

@koyaanisqatsi - Vielen Dank für den Hinweis!

Unglaublich! Das dies seit dem Release der 6.83 im März (und früher?) in den Labors noch nicht gelöst wurde.
Als ob IPv6 in Dual Stack eine exotische Variante wäre. Das meine ich wenn ich sage das all die neuen Features
wenig(er) bringen wenn so etwas ärgerliches in einem Produktionsrelease auf einmal auftaucht.

Ich hoffe sehr das dies bei AVM bekannt ist und in Kürze behoben wird.
Hast Du vielleicht entsprechende Referenzen/Links?

Ich habe in der Tat einen, nach Jahren noch immer in der Probephase verkehrenden, 6rd IPv4/IPv6 Anschluss.
Gerade die IPv6 Freigaben meiner beiden NAS, unter "server1(2).subdomain.pwnz.org", möchte ich aber nicht verlieren.

Wenn ich die 7390 heute abend mal wieder kurzzeitig durch die 7490 ersetze, werden wir testen
(mehr aber erstmal nicht). - Tagsüber geht es leider nicht, dann kriege ich hier Ärger.

 

[koyaanisqatsi]

Referenzen auf das Problem ?
1. Netzwerkeinstellungen: IPv4 Routen funktionieren nur bei deaktivierten IPv6
2. Gastzugangsvorschaltseite: Nach Bestätigen nur IPv4 Internet (bei aktivierten IPv6)
...erst zweiter Aufruf und "Akzeptieren" von fritz.box:8185 (IPv6) schaltet IPv6 frei.
3. IPv6 Dual Stack verrät den individuellen Teil der Klienten-MAC im Internet
...aber Letzteres* scheint ja normal zu sein und allgemein akzeptiert.

Hab IPv6 einfach mal deaktiviert, da ich ja eine "echte" IPv4 bekomme.
...die ich auch für VPN (über DynDNS) benötige.


* So lassen sich alle Klienten prima verfolgen, auch ohne Googles Cookies.

 

[morenoralfo]

@koyaanisqatsi

1. Scheint mir eventuell relevant zu sein im Produktivbetrieb
2. "Gastzugangsvorschaltseite" - So etwas ist hier in den Niederlanden eigentlich nicht nötig,
es gibt hier z.B. keine sogenannte "Störerhaftung".
3. Das war mir beim Einrichten der IPv6 Freigaben natürlich schon bekannt.
Da dies hier im wesentlichen aber nur den Zugang von aussen betrifft, NAS surfen ja bekanntlich nicht,
habe ich damit keine Probleme.

OT:
Meine PC's sind mit "Privacy Extensions for slaac in IPv6" (und z.T. der 4or6-extension in FF, Noscript, Ghostery, Privacy Badger) unterwegs
und Android (bzw. iGeräte) lassen sich wahrscheinlich auch auf andere Weise innerhalb der benutzten Apps identifizieren.

 

[morenoralfo]

Wie im heutigen! Beitrag von SuperBigAl auf www.router-forum.de gemeldet wurde
scheint der AVM Support das geschilderte Problem mit den fehlenden/fehlerhaften
Supportdaten nachgestellt und 6 Wochen nach der ursprünglichen Meldung bestätigt! zu haben.

 

[stoney]

Super danke für die Info

Dann heißt es abwarten - wie oft benötigst Du denn die Supportdaten?

 

[morenoralfo]

Ich benötige die Supportdaten eigentlich nicht (häufig), AVM fragt danach in Verbindung mit einem anderweitig gemeldeten abweichenden Verhalten (=Ticket über nicht (mehr) richtig erstellte MyFritz IPv4/IPv6 Freigaben). - Aber scheinbar bin ich dabei zufällig? auf das Supportdatenproblem gestossen. (Schlaglochsuchen nennt man das wohl)

 

[PeterPawn]

@morenoralfo:
Bist Du eigentlich sicher, daß im router-forum.de auch das Problem mit den Support-Daten gemeint war (was AVM bestätigt haben soll) und nicht etwas das (eigentliche) VPN-Problem?

Wenn Du einen Shell-Zugang haben solltest (wenn nicht, verschaffe Dir einen), kannst Du auch einfach "/bin/supportdata" aufrufen und die Ausgabe in eine Datei umlenken ... das ist exakt dasselbe, was über das GUI kommen würde. Vor allem kann man da - so es wirklich reproduzierbar ist - dann auch sehen, bei welcher Operation das Problem auftritt. Läuft das hingegen auf der Kommandozeile sauber durch, kann es ja eigentlich nur der Webserver sein, der beim Download Probleme macht.

Wie sieht es eigentlich mit der 2FA aus? Da ggf. einige Aktionen seit deren Einführung zusätzlich geschützt sind, würde ich diese entweder probehalber mal abschalten oder zumindest vor dem Download der Support-Daten dafür sorgen, daß die verwendete Sitzung bereits mit der 2FA autorisiert wurde - das wird für die Dauer der Sitzung intern vermerkt und dann nicht erneut abgefragt.

Es gibt in diesen Supportdaten sehr viele "cat /proc/foo"-Statements, mit denen Daten aus irgendwelchen procfs-Pseudo-Dateien eines Kernel-Treibers ausgelesen werden ... da reicht es bereits, wenn eines davon hängen bleibt und kein "end of file" signalisiert wird bei einem weiteren Leseversuch. Da diese Support-Daten das Ergebnis der (sequentiellen) Abarbeitung der "/bin/supportdata" sind, kommt das dann nicht zu einem Ende ... es gibt da kein "Timeout" für einzelne Kommandos, wo es dann einfach weitergeht, wenn eines davon abgebrochen wurde.

Auch an einer anderen Stelle (dem - internen - Export von Einstellungen) kommt es in den jüngeren Versionen reproduzierbar zu einem Problem, das dem beschriebenen ähnelt - dort bleibt der Aufruf von "tr069fwupdate configexport" ebenfalls hängen.

Schaut man dann in den neuen Mesh-Versionen genauer hin, liegt es dort aber neuerdings an dem Versuch, eine E-Mail zum Thema "Einstellungen wurden gesichert" über den "ctlmgr" zu versenden (pushmail 23 6 tr069) - das funktioniert normalerweise problemlos, wenn es über das GUI gestartet wird. Aber über die Kommandozeile aufgerufen ("/bin/supportdata" ist am Ende auch "Shell"), hängt es sich reproduzierbar auf - der "ctlmgr" reagiert einfach nicht auf die RPC-Nachricht an seinen Socket.

Vielleicht ist es also auch mal einen Versuch wert, alle neueren Push-Mails zu Sicherheitsthemen auszuschalten, bevor man den Download der Support-Daten versucht ... das ist ja auch ein entscheidender Punkt, der zur 06.83 hin geändert wurde und den Unterschied im Verhalten zu früheren Versionen erklären könnte.

Auch wenn es für die Support-Daten m.W. keine eigene Mail gibt, könnte irgendeine Einstellung zum "automatischen Versand" da dann doch wieder dazwischenfunken (und sei es bei einer Prüfung, die keine Aktion nach sich ziehen würde) und zwischen der deutschen und der internationalen Version gibt es dann wieder genug Unterschiede in den tatsächlich vorhandenen Dateien (und Pseudodateien), daß es auch da kein Wunder wäre, wenn eine in der deutschen Version nicht vorhandene Datei zu diesem "Hängenbleiben" führt (und das niemand richtig getestet hat bei der internationalen).

 

[morenoralfo]

@PeterPawn

Naja - so eindeutig ist die Antwort des Posters nicht, obwohl ich eindeutig nur das Problem mit den Supportdaten anspreche.
Ich habe nochmals nachgefragt.

Noch was info:
Das (Teil)laden der gesicherten Daten (6.20 dts -> 6.83 int.) erfolgt immer ohne Fehlermeldung.
Vorab habe ich Interface und Landeinstellungen auf Deutsch eingestellt.


2FA ein/aus hat (leider) keinen Einfluss auf das Auftreten des geschilderte Problems.

Merkwürdigerweise wird nach einem Abbruch des ersten fehlgeschlagenen Downloads auf einem Tablet bei einem erneuten Versuch, diesmal aber auf einem PC, überhaupt kein Dateiname mehr übermittelt, d.h. auch keine Datei mehr angelegt.
Das lässt sich auch auf dem PC (ohne Tablet) reproduzieren, es bleibt beim zweiten und allen weiteren Versuchen bei "verbinden".

Lässt das auf ein Problem mit dem auslesen von "cat /proc/foo"-Statements schliessen?

Erst nach einem Reboot der Box findet bei einem ersten Versuch wieder ein unvollständiger Downloadversuch statt.

Beim erstenmal kommt der Download niemals viel weiter als etwa bis zu:

End Of Support Data Basis
##### END SECTION Basis
##### BEGIN SECTION System_Status System status

System Status
-------------
FRITZ!Box 7490-B-120200-000614-015777-760102-787902-1130683-43890
##### END SECTION System_Status
##### BEGIN SECTION varlogmessages
##### END SECTION varlogmessages
##### BEGIN SECTION DSL Supportdata xDSL

DSL SUPPORT DATA
----------------

VERSIONS:
---------
DSL_SDK_VERSION: 1437
VINAX_TOOLS_VERSION: 737
DSL_ARCH_VERSION: 1298
DSL_ARCH_VERSION: 29

cat /var/flash/xdslmode
-----------------------

cat /var/dsl/*
--------------
File: /var/dsl/dsl_versions.txt
5.9.0.C.1.7
5.9.0.A.0.2
1.100.135.14
1.100.8.17

File: /var/dsl/vdsl_init.cfg


Auch das Ausschalten der Pushmails hat keinen sichtbaren Einfluss.

Laborversionen gibt es (leider?) nicht für die internationale Box, also auch keine Mesh Sachen.

Wenn ich so nach der relevanten? Email-Korrespondenz mit dem AVM Supportmitarbeiter gucke (ohne Supportdaten tut der nichts), bezweifle ich das irgendwelche Resultate von z.B. von einem Shell-Zugang einen kompetenten Mitarbeiter in endlicher Zeit erreichen werden.
(The Great AVM Firewall oder sowas) -
Aus Neugier könnte ich es aber trotzdem mal versuchen, obwohl der Erkenntnisgewinn grenzwertig ist.

 

[PeterPawn]

Das mit dem Scheitern des zweiten Versuchs ist zumindest zu erwarten, wenn da tatsächlich die erste Instanz noch "hängt". Das Binary "firmwarecfg" ist wohl immer noch als "Singleton" angelegt (darauf basierte z.B. auch dieser DoS-Angriff) und wenn da die vorherige Instanz noch aktiv ist, wird vermutlich keine zweite gestartet. Zumindest spräche diese Beobachtung auch dafür, daß die erste Instanz eben irgendwo steckenbleibt und es kein Problem der Übertragung über den Webserver ist.

Wenn das immer im DSL-Teil ist (der wird in einer gesonderten Datei "supportdata.dsl" zusammengestellt), dann ist es wohl wirklich ein systematischer Fehler ... schon nur für die Ermittlung, welches Kommando das nun konkret ist, lohnt sich aber u.U. ein manueller Aufruf mit "sh -x /bin/supportdata.dsl".

Wenn es Dir am Ende um die Lösung Deines MyFRITZ!-Problems geht, wird Dir (meiner Meinung nach) nicht viel anderes übrig bleiben, als den AVM-Support an dieser Stelle "auszutricksen" ... wenn Du nicht erst auf die nächste internationale Version warten willst, in der dann vielleicht auch das Problem mit den Support-Daten behoben ist, aber Dein MyFRITZ!-Problem u.U. eben noch nicht - womit sich das dann wieder auf die nächste Version verlagert.

Auch nach einem erfolgreichen Shell-Zugang kann man noch gültige Support-Daten erzeugen ... solange man den Zugang nicht mit dem Aufruf von "ar7login" koppelt, erscheint auch das "Vom Hersteller nicht unterstützte Änderungen"-Flag nicht in den Support-Daten und man muß nur noch den Abschitt mit der Prozessliste passend "fälschen", damit das nicht mehr auffällt, wenn man die Support-Daten von Hand erzeugt. Das ist sicherlich nicht ganz die "feine englische Art", aber sofern da vom Hersteller nichts kommt und die Lösung des Problems sich damit immer weiter verzögert, würde ich das als Notwehr durchgehen lassen.

Ich denke auch nicht, daß es irgendetwas bringt, wenn ein anderer jetzt seine 7490 zusätzlich mit einer internationalen Version versieht und da funktioniert dann das Erstellen der Support-Datei. Im Verlauf des Erstellens der DSL-Supportdaten kommt nämlich irgendwann (auch in der Nähe dessen, wo das nach Deinem Bericht immer abbricht) ein Aufruf von "/usr/sbin/dsl_monitor --supportdata all" und spätestens der dürfte dann "sehr speziell" für den jeweiligen DSL-Anschluß sein. Wenn da die Ermittlung irgendeines Wertes aus dem DSL-Treiber an Deinem Anschluß nicht richtig klappt (das kann ja irgendeine seltene Kombination sein), dann kann man das kaum an einem anderen Anschluß nachstellen.

Daher sehe ich als einzige (noch in diesem Leben realistische) Möglichkeit eben an, daß Du selbst einmal nachverfolgst, wo das nun genau klemmt und dann kann man sich Gedanken machen, wie man das ggf. umgehen kann. Sollte es tatsächlich der o.a. Aufruf sein, würde z.B. ein deaktiviertes DSL-Modem schon helfen (dann liefert der DSL-Monitor gar keine Daten und nur eine einzelne Zeile mit einer Fehlermeldung) und Dein MyFRITZ!-Problem sollte sich ja auch bei einer Box mit LAN1 als WAN-Verbindung reproduzieren lassen.

 

[morenoralfo]

Glücklicherweise? (oder auch nicht) habe ich keinen dsl sondern einen ftth Anschluss - warum da etwas beim Auslesen der dsl daten daneben geht? DSL ist deaktiviert! Soviel Kenntnisse bzw. Phantasie habe ich nicht. - Ich benutze wohl das Y-Kabel von AVM aber nur um den Telefonanschluss meines Glasfiber Mediakonverters in die Box zu kriegen. WAN-anschluss erfolgt über LAN1 an einen Switchport des Konverters.
- Vollständigkeitshalber: Auch ohne DSL/POTS Kabel erhalte ich keine Supportdaten

 

[PeterPawn]

Dann würde ich erst recht nachsehen in einer Shell ... dann kann da ja eigentlich nur etwas wegen des deaktivierten Modems in den DSL-Daten hängenbleiben und so ein deaktiviertes Modem dürfte/müßte nun jeder haben, der seine Box mit LAN1 als WAN-Port betreibt. Das macht es ja dann noch unerklärlicher ... zumindest bei mir kommt sauber die Meldung:

$ /usr/sbin/dsl_monitor --supportdata all
[WARN DSL SUPPORTDATA] arch drv not ready

, wenn die Box ohne DSL-Modem läuft.

Aber das mit dem "dsl_monitor" als konkrete Stelle war ja ohnehin nur eine mögliche Idee und Stelle von vielen ... das mußt Du schon selbst klären (wenn es Dich weiterhin interessiert), was da nun konkret das Problem verursacht. So einen Skript-Aufruf in der Shell kann man i.d.R. auch entsprechend abbrechen, wenn er hängt ... das Problem mit dem nur einmal möglichen Aufruf pro Systemstart rührt von "firmwarecfg" her (jedenfalls mit höchster Wahrscheinlichkeit) und nicht von dem Skript "/bin/supportdata.dsl" (auch wenn das am Ende dazu beiträgt, wenn "firmwarecfg" nicht fertig wird).

Wobei mich schon mal interessieren würde, ob auch hier die ~40 Minuten bis zum Request-Timeout für "firmwarecfg" greifen und die Ausführung von "/bin/supportdata" abgebrochen wird ... sprich, ob nach ca. einer 3/4 Stunde dann auch wieder eine Anfrage nach den Support-Daten möglich ist.

So ein Hängenbleiben von "firmwarecfg" beeinflußt aber (zumindest bisher) auch noch alle möglichen anderen Funktionen ... auch ein Export dürfte nicht mehr funktionieren (auch ein Import nicht, was man ja mit einer (später abgebrochenen) teilweisen Übernahme testen könnte ohne jede Änderung der Firmware) und praktisch alles, wo "firmwarecfg" benötigt wird, sollte nach dem ersten Downloadversuch für die Support-Daten ebenfalls blockiert sein.

 

[morenoralfo]

@PeterPawn
Die *.part Dateien enden nie an exakt derselben Stelle.
Wie Du hier unten siehst erhalte ich auch die von Dir genannte Meldung:

[WARN DSL SUPPORTDATA] arch drv not ready

Nur nicht ganz so sauber wohl.

Die anderen Sachen mit dem Timeout etc. werde ich vielleicht nach dem Abendessen checken.

cat /var/log/dsl_ui.txt
-----------------------

cat /var/log/dsl_libremotemgmt.txt
----------------------------------
[RMGMT MAIN][FORCE]avmDslRemoteMgmtIf_Init

[WARN DSL SUPPORTDATA] arch drv not ready

DSL Line Test
-------------

Calibrate Echo              : 3
Measure Echo                : 0
Cable NOK Distance (m)      : 0

DSL Configs
-----------

Max Downstream Rate         : 0
Max Upstream Rate           : 0
RFI                         : 0
DownstreamBlackoutBandStart : 0
DownstreamBlackoutBandEnd   : 0
ControlBitfield             : 0x00000000
Extra DownstreamMarginOffset: 0
Extra DownstreamPcbOffset   : 0
Extra UpstreamPcbOffset     : 0
DiagControlBitfield         : 0x00000000
DiagnosticEnabled           : 0
Annex                       : B
IsAnnexSet                  : 1
DSLMode                     : 0
IsDSLModeSet                : 0
XTSE Octet 1                : 0x00
XTSE Octet 2                : 0x00
XTSE Octet 3                : 0x00
XTSE Octet 4                : 0x00
XTSE Octet 5                : 0x00
XTSE Octet 6                : 0x00
XTSE Octet 7                : 0x00
XTSE Octet 8                : 0x00
VDSL2 Profiles Octet 1      : 0x00
UsNoiseBits                 : 0
RFI_mode                    : 0
DsINP                       : 0
IsLastReleasedDP            : 0
DSL Disabled (ATA)          : 1
Fullbridge                  : 0

DSL Platform Specific
---------------------

cat: can't open '/proc/driver/ifx_atm/mib': No such file or directory

cat: can't open '/proc/driver/ifx_ptm/wanmib': No such file or directory

cat: can't open '/proc/eth/mib': No such file or directory