Fritzbox 6490 Cable Firmware Update?

[PeterPawn]

Die bei dem Test verwendeten support-Daten waren aber noch von der Box ohne die provideradditive in Node 29...

Da sollte trotzdem ein früherer Eintrag für Node 29 existieren, sonst würde er keinen doppelten finden (das macht er daran fest, ob bereits eine Datei ($id.bin) existiert, wenn ich mich richtig erinnere).

Willst Du das genauer wissen? Ich habe beim "dissect..." ein "Inhaltsverzeichnis" der gefundenen Einträge mit ID, Offset und Länge nachgerüstet - das müßte ja dann bei der oben verwendeten Vorlage auch einen Eintrag für "NODE=29" enthalten.

Ansonsten kann eigentlich nur noch die doppelte Angabe von "node filename" für dieselbe Node-Nummer zu solchen doppelten Einträgen führen, da gibt es keine Prüfung. Die baue ich auch nicht ein ... obwohl das Skript ja nicht nur für die "provideradditive.tar" bei der 6490 zu gebrauchen ist - hier gehe ich mal fest davon aus, daß AVM irgendwann tätig wird und die Lücke (hoffentlich nicht nur für DOCSIS-Boxen) dann doch schließt - nur dafür würde sich ein solcher Aufwand dann wirklich nicht lohnen.

Ich habe das u.a. auch aufgelegt, weil man auf diesem Wege besser automatisch ein eigenes Zertifikat für das GUI in die Box bringen kann ... das geht im Moment zwar auch über den passenden HTTP-Aufruf für "firmwarecfg", aber es ist gegenüber Änderungen seitens AVM eben anfälliger als das "an der Wurzel" selbst auszutauschen. Mit Export-Datei ist da ja bekanntermaßen nichts zu machen und der Import über "firmwarecfg" bzw. das GUI krankt auch daran, daß die zusätzlich in der Zertifikat-Datei vorhandenen "DHPARAM"-Werte für eine individuelle Einstellung zwar vom Webserver (ctlmgr) akzeptiert und berücksichtigt werden, aber beim Import werden die nicht übernommen. Man muß also für eigene (sicherere) Parameter (Stichwort "LogJAM") ohnehin noch einmal "von Hand" nacharbeiten, das geht über ein eigenes TFFS-Image dann auch auf Boxen, wo man keinen Shell-Zugang hat (und braucht). Es ist also tatsächlich auch an anderen Stellen noch zu nutzen und nicht nur für diesen speziellen Fall hier geschrieben ... auch mir selbst gingen die Laufzeiten der Skript-Dateien bei mehr oder minder regelmäßiger Benutzung auf die Nerven.

Wobei ich inzwischen schon so lange mit eigenen DH-Parametern arbeite (und das auch nicht regelmäßig kontrolliere), daß ich gar nicht mehr genau weiß, was die originale AVM-Firmware inzwischen als Parameter "eingebaut" haben mag - vielleicht ist man da inzwischen auch von den 512-Bit als Standard abgekommen.

- - - Aktualisiert - - -

@PeterPawn: Hab ich das richtig verstanden, dass das tffs_add_file auch gleich die Segment-ID ändert um vom System als aktuelleres tffs erkannt zu werden?

Ja, der zu subtrahierende Wert (für sehr alte Support-Daten) läßt sich sogar festlegen, der Standard ist 16.

 

[Pokemon20021]

Thema Serial Number

Nochmal zum Thema Serial Number, die wird per DHCP Option 43 übermittelt.

Ich kann garantieren, dass diese Serial übermittelt wird, ohne wird auch hier kein Modem freigeschaltet. Im Aktivierungsportal werden diese Daten auch angezeigt wenn der Kunde sein Modem aktivieren will.

Oder per SNMP mal auf der eigenen Box auslesen -> docsDevSerialNumber

Allerdings hat diese Serial komischerweise nix mit der auf dem Aufkleber der Box zu tun
Ist bei den "meisten" Fritzboxen die letzten 3 Octets der MAC Adresse.

ich habe mal die DHCP-Traces

DHCP Option 43 - Vendor Specific Information text: ..ECM..ECM:EMTA:EROUTER..20:01:XX..213.4..141.06.6 2..1.2411..C80E14..6490..AVM GmbH..EROUTER

mit dem PDF-Dokument aufgearbeitet:

Page 17:
4.1.1.6 DOCSIS Cable Modem with Embedded Router

DHCP DISCOVER Options:	Value example:	Value FB6490:	Description:
eCM Option 43 sub-option 1		N/A	List of sub-options (within option 43) to be returned by server
eCM Option 43 Sub-option 2	<Device Type>	ECM	Embedded cable modem
eCM Option 43 Sub-option 3	"ECM:<eSAFE1:eSAFE2…SAFEn>"	ECM:EMTA:EROUTER	ECM followed by a list of embedded components (eSAFEs)
eCM Option 43 Sub-option 4	"<device serial number>"	20:01:XX	Device serial number as in MIB object docsDevSerialNumber
eCM Option 43 Sub-option 5	"<Hardware version>"	141	Hardware version number as in <Hardware version> field in MIB object sysDescr
eCM Option 43 Sub-option 6	"<Software version>"	06.62	Software version number as in <Software version> field in MIB object sysDescr
eCM Option 43 Sub-option 7	"<Boot ROM version>"	1.2411	Boot ROM version number as in <Boot ROM version> field in MIB object sysDescr
eCM Option 43 Sub-option 8	"<OUI>"	C80E14	6-octet OUI as Vendor ID
eCM Option 43 Sub-option 9	"<Model number>"	6490	Device model number as in <Model number> field in MIB object sysDescr
eCM Option 43 Sub-option 10	"<Vendor name>"	AVM GmbH	Vendor name as in <Vendor name> field in MIB object sysDescr

Frage: Sehe ich es richtig, dass im VKD Aktivierungsportal die via DHCP-Option-43, SubOption 4 und 8 übermittelte Daten dargestellt werden ?
und dies entspricht der eRouter-MAC-Adresse ?

LG Pokemon20021

 

[PeterPawn]

Ich staune mehr darüber, daß da als Komponente auch noch "EMTA" angesagt wird.

Entweder das ist wirklich weiterhin durch den Provider konfigurierbar (was dann meine Aussage, daß der Provider automatisch auch die Telefonie wg. fehlender PACM-Komponenten nicht konfigurieren könnte, selbst wenn er wollte, wieder falsifizieren würde) oder da ist in den Konfigurationseinstellungen fälschlicherweise noch ein EMTA aktiviert (der DHCP-Client sollte da über das Plugin "/lib/libdocsis_dhcp4plg.so" aus der DOCSIS-Datenbank lesen mit "DocsisDb_GetMtaEnabled", wenn ich das richtig interpretiert habe).

Hier könnte ich mir noch vorstellen, daß die DOCSIS-DB von einer Provider-Firmware angelegt wurde, wenn das keine originale Retail-Box ist, die bereits mit Retail-Firmware ausgeliefert wurde. Ich weiß nicht, wo die betreffende DB liegt, aber dsa wird wohl irgendwo unter /nvram sein, die Frage ist nur, ob in einem beim Werksreset gelöschten Verzeichnis. Vielleicht war das aber auch wirklich ein Update ohne Werkseinstellungen? Oder ist das eMTA ansprechbar oder zumindest konfigurierbar, auch mit Retail-Firmware?

Vielleicht kann ja @scuros etwas dazu schreiben, ob eine FRITZ!Box 6490 mit Retail-Firmware eMTA-Einstellungen im config-File berücksichtigt oder nicht - er sollte es testen können (auch wenn dort wohl EPC 1.5 verwendet wird, es geht ja nur darum, ob die FRITZ!Box die Einstellungen übernimmt (Support-Daten), nicht ob sie auch funktionieren).

Das würde dann zumindest auch erklären, warum bei UM die Telefonie weiterhin funktionieren soll, wenn man die Firmware einer Provider-Box auf eine Retail-Version ändert ... erstens würde weiterhin das Vorhandensein eines eMTA signalisiert und - sofern der Provider auf den "Management"-Anteil der PACM-Komponenten keinen Wert legt - wenn dann keine neue Telefonie-Konfiguration über SNMP eingestellt oder verwaltet wird (dafür fehlen dann nach meiner Ansicht auch wieder die notwendigen Dateien), dann bleiben halt die alten Einstellungen in der "voip.cfg" erhalten, während gleichzeitig noch das nötige eMTA-Interface aktiviert und konfiguriert wird.

Vielleicht findet sich ja mal jemand, der an einem UM-Anschluß mit so einer aktualisierten OS-Version (auch wenn ich immer wieder davon abrate, wird es sicherlich jemanden geben - zumindest jemanden, der es temporär testen kann) die Support-Daten einer Box mit funktionierender Telefonie (wo also der Provider gar nicht weiß bzw. nicht zur Kenntnis genommen hat, daß die Firmware auf eine Retail-Version aktualisiert wurde) auslesen kann. Mangels UM-Anschluß (auch KDG/VF geht bei mir nicht mehr, ich habe zwar den Anschluß, aber keinen Vertrag mehr) kann ich da immer nur wie eine Figur aus einer Felsenstein-Inszenierung (und ich bin eigentlich kein Milchmann) mit "einerseits, aber andererseits" argumentieren ... nur der Blick in die tatsächlichen Einstellungen schafft endgültig (zumindest für den konkreten Fall) Aufklärung Klarheit.

 

[Pokemon20021]

Oder per SNMP mal auf der eigenen Box auslesen -> docsDevSerialNumber

Wie kann ich die MIB objecte docsDevSerialNumber sowie sysDescr aus der FB6490 auslesen ?

 

[PeterPawn]

Für diejenigen, die mit einem selbst geänderten Dateisystem arbeiten:

Ich habe das Shell-Skript für den Einbau ins GUI als "Boot-Manager" auf der "Neustart"-Seite so geändert, daß es jetzt auch mit der 6490 (und deren anderem Aufbau bei den Partitionen) funktioniert.

Ein Beispiel, wie das in die Seite eingebunden werden kann, gibt das dazugehörige "modscript" für "modfs" - da dieser Teil des GUI auf dem ARM-Core läuft, gehört das dann auch in dessen Dateisystem. Wer den Aufruf nicht von Hand in die Lua-Seite basteln will, kann das "modscript" normalerweise problemlos auch außerhalb von "modfs" aufrufen.

Ggf. ist im Skript der Name der Datei, aus deren Erstellungdatum das Änderungsdatum des Dateisystems abgeleitet wird (Variable "statfile"), anzupassen - die Datei im YourFritz-Repo verwendet dort die "var.tar" auf dem Wurzelverzeichnis des Dateisystems, während das "modscript" auf eine Datei zurückgreift, die vom "modfs" beim Packen hinzugefügt wird.

 

[PeterPawn]

Für die Weiterleitung des Zugriffs auf das GUI über die IP-Adresse des ARM-Cores, wenn der Benutzer zum FRITZ!NAS will, klappt im internen Netz ja ein simples HTTP-Redirect auf die IP-Adresse des x86-Core (302 mit einer URL für den x86-Core, die auch gleich eine passende SID enthält, damit da keine neue Anmeldung (ist ja ein anderes System) erforderlich wird.

Daher steht bei der 6490 bei NAS-Zugriff über das GUI auch die IP-Adresse in den Links, selbst wenn der Zugriff ursprünglich über einen Namen erfolgte - solange man nicht über "[www.]fritz.nas" direkt auf den x86-Core zugreift.

Wenn jetzt jemand von extern kommt und auf das NAS will, dann könnte der ARM-Core zwar auch als Reverse-Proxy wirklich jedes Paket bis L5 und darüber verarbeiten ... aber der ist wohl schon lahm genug und da die externe Freigabe für 12345 ja schon auf den ARM-Core zeigt, braucht es (an derselben externen IP-Adresse) einen anderen Port, wenn man das wenigstens auch durch den PA kriegen will - für den ist ja die .254 ein "normaler" Host im LAN und da muß der ARM-Core gar nicht in jedem einzelnen Paket auf die Details schauen. Bei einem Reverse-Proxy müßte ja jedes Paket in beiden Richtungen immer komplett durch den IP-Stack auf dem ARM-Core wandern, wenn man von extern auf das NAS zugreifen will.

Insofern hat das AVM m.E. gar nicht so schlecht gelöst ... ist halt etwas irritierend mit der Meldung und (afaik) bisher eher schlecht dokumentiert (auch in der AVM-KB) - wie die ganze Problematik mit dem zweiten Core und der zweiten IP-Adresse im LAN (was ja beim Einbinden der FRITZ!Box in ein bestehendes Netz schon ein echter Stolperstein ist).

Auch bei der SAT>IP-Unterstützung findet man wenig bis keine Dokumentation oder Anleitung von AVM. Nur die Einbindung in Kodi über "IPTV Simple Client" ist halbwegs beschrieben, aber auch ohne jeden Hinweis, daß pro IP-Adresse nur ein Stream machbar ist (zumindest war, habe ich auch mit der Retail-Box noch nicht getestet). Wenn man dann keinen Client hat, der wirklich selbst das Netz per UPnP beobachtet (in den SSDP-NOTIFY-Paketen steht die richtige Adresse drin) und man das von Hand konfigurieren will, wird ja "fritz.box" auch nicht helfen, weil das eben der falsche Core ist. Wenigstens der Hinweis, daß die SAT>IP-Funktionen über den Namen "fritz.nas" erreichbar sind, wäre in der KB ja sinnvoll und könnte bestimmt so manchem helfen. Kodi auf einem RasPi ist ja ausreichend oft beschrieben, das Einbinden der 6490 als Vierfach-Tuner eher weniger.

 

[criens]

EDIT2: Und weil PeterPawn mein schönes Listing hier zu kompliziert erschien, hat er kurzerhand ein nettes script tffs_add_file in sein Repo eingecheckt. Es dient primär dazu beliebige Inhalte ins tffs zu packen oder Nodesinhalte auszutauschen. Es holt sich netterweise auch gleich die enviroment-Variablen und counter aus der support-Datei. Das ganze Prozedere hier unten reduziert sich damit nun auf das Erstellen (oder Herunterladen) der provideradditive.tar (Punkt 3), einen Einzeiler und das eigentliche flashen/updaten (Punkt 5.3 bis :

./tffs_add_file /<pfad_zur>/support\ FRITZ.Box\ 6490\ Cable\ 141.xxxxxx.txt -o 5 29 /tmp/provideradditive.tar > /tmp/mtd.img

Achso: laut PeterPawn braucht man jetzt das erstellte tffs-Image auch nicht mehr in beide mtd-Partitionen schreiben (Punkt 5.5/5.6). Es reicht wenn man in eine von beiden beschreibt, das System erkennt die aktuellere automatisch anhand der geänderten Segment-ID.

An alle Experten:
Ich habe heute meiner KDG-Fritz über den beschriebenen Weg ein Update verpasst. Leider bootet die Fritz auf FS1 (vorherige Firmware 06.31) danach in einer Schleife. Über FS2 komme ich noch an die Box (Firmware 06.50).
Das Log zum Update sieht so aus:

+ test -f /var/media/ftp/newfirmware.image
+ test -f /var/media/ftp/newfirmware.image
+ stat -c %s /var/media/ftp/newfirmware.image
+ fsize=35727360
+ test 35727360 -eq 0
+ tarlist=/var/tmp/run_update.1943.list
+ tar -t -v -f /var/media/ftp/newfirmware.image
+ test -s /var/tmp/run_update.1943.list
+ sed -n -e s|.*\(var/tmp/filesystem.image\).*|\1|p /var/tmp/run_update.1943.list
+ test var/tmp/filesystem.image = var/tmp/filesystem.image
+ sed -n -e s|.*\(var/tmp/kernel.image\).*|\1|p /var/tmp/run_update.1943.list
+ test var/tmp/kernel.image = var/tmp/kernel.image
+ sed -n -e s|.*\(var/install\).*|\1|p /var/tmp/run_update.1943.list
+ test var/install = var/install
+ test -f /var/media/ftp/check_signed_image
+ tar -C / -x -f /var/media/ftp/newfirmware.image
+ grep -B 5 ^[ \t]*if *\[ *"$i" *= *"${OEM}" *\] *; *then[ \t]*$ /var/install
+ sed -n -e s|for *i *in *\(.*\) *; *do|\1|p
+ echo avm
+ brandings=avm
+ found=0
+ changebranding=0
+ test avm = avm
+ found=1
+ break
+ test 1 -eq 0
+ test 1 -eq 0
+ test 0 -eq 1
+ sed -e s|>[ ]*/dev/console|>\&6|g /var/install
+ mv /var/tmp/install.tmp /var/install
+ test 0 -eq 1
+ force=
+ pwd
+ opwd=/
+ cd /
+ /bin/sh /var/install
install: have Kernel 2.6.39.3 - set kversion '2.6.39' and FlashUpdateTool '/lib/modules/2.6.39.3/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=
ANNEX=Kabel
testing acceptance for device Fritz_Box_HW213a ...
korrekt install type: arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
device has installtype arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
assumed ANNEX Kabel -- found ANNEX Kabel
device has ANNEX Kabel
OK - accept this update for device Fritz_Box_HW213a ...
testing acceptance for device Fritz_Box_HW213a done
curr: 141.06.50  new: xx.06.63
debug: curr: 141.06.50
debug: new: "XX.06.63"
major_currFWver=141
middle_currFWver=6
minor_currFWver=50
middle_newFWver=6
minor_newFWver=63
check Firmware Version: xx.06.63
DEBUG: 6 >= 6
DEBUG: 63 >= 50
Accept Firmware Version: xx.06.63
install: 2.6.39 check files...
read 0xb5b7b747 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xb5b7b747
Calculated checksum is B5B7B747
Saved checksum is B5B7B747
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/filesystem.image ok
size for file /var/remote/var/tmp/x86/filesystem.image ok
read 0x69120b31 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x69120b31
Calculated checksum is 69120B31
Saved checksum is 69120B31
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/kernel.image ok
size for file /var/remote/var/tmp/x86/kernel.image ok
read 0xd53c86f3 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xd53c86f3
Calculated checksum is D53C86F3
Saved checksum is D53C86F3
Checksum validation successful!
chksum for file /var/remote/var/tmp/filesystem.image ok
size for file /var/remote/var/tmp/filesystem.image ok
read 0xc9040a34 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xc9040a34
Calculated checksum is C9040A34
Saved checksum is C9040A34
Checksum validation successful!
chksum for file /var/remote/var/tmp/kernel.image ok
size for file /var/remote/var/tmp/kernel.image ok
/var/install [2083]: +++++++++++++ update start
/var/install [2083]: +++++++++++++ FlashCMDs (to be executed):
/var/install [2083]: +++++++++++++ ATOM Kernel     FlashCMD: dd if=/var/remote/var/tmp/x86/kernel.image of=/dev/mmcblk0p8 count=2048 bs=4096 conv=sync
/var/install [2083]: +++++++++++++ ATOM Filesysten FlashCMD: dd if=/var/remote/var/tmp/x86/filesystem.image of=/dev/mmcblk0p7 count=16384 bs=4096 conv=sync
/var/install [2083]: +++++++++++++ ARM Kernel     FlashCMD: dd if=/var/remote/var/tmp/kernel.image of=/dev/mmcblk0p6 count=2048 bs=4096 conv=sync
/var/install [2083]: +++++++++++++ ARM Filesysten FlashCMD: dd if=/var/remote/var/tmp/filesystem.image of=/dev/mmcblk0p5 count=16384 bs=4096 conv=sync
/var/install [2083]: +++++++++++++ ATOM flash kernel
902+1 records in
903+0 records out
/var/install [2083]: +++++++++++++ ATOM check kernel
/var/install [2083]: +++++++++++++ ATOM md5sum of kernel image: 40a881256c2419ad96fa3941f495ee2c  
/var/install [2083]: +++++++++++++ ATOM size of kernel image: 3697840
/var/install [2083]: +++++++++++++ ATOM md5sum of kernel mtd : 40a881256c2419ad96fa3941f495ee2c  
/var/install [2083]: +++++++++++++ ATOM write to /dev/mmcblk0p8 done
/var/install [2083]: +++++++++++++ ATOM flash filesystem
3273+1 records in
3274+0 records out
/var/install [2083]: +++++++++++++ ATOM check filesystem
/var/install [2083]: +++++++++++++ ATOM md5sum of filesystem image: 0e552a8ff1abecbb36a5dfc94c3ac86b  
/var/install [2083]: +++++++++++++ ATOM size of filesystem image: 13408044
/var/install [2083]: +++++++++++++ ATOM md5sum of filesystem mtd : 0e552a8ff1abecbb36a5dfc94c3ac86b  
/var/install [2083]: +++++++++++++ ATOM write to /dev/mmcblk0p7 done
/var/install [2083]: +++++++++++++ ARM flash kernel
443+1 records in
444+0 records out
/var/install [2083]: +++++++++++++ ARM check kernel
/var/install [2083]: +++++++++++++ ARM md5sum of kernel image: fa185616c693b50190b7f14a6ab01fa8  
/var/install [2083]: +++++++++++++ ARM size of kernel image: 1818288
/var/install [2083]: +++++++++++++ ARM md5sum of kernel mtd : fa185616c693b50190b7f14a6ab01fa8  
/var/install [2083]: +++++++++++++ ARM write to /dev/mmcblk0p6 done
/var/install [2083]: +++++++++++++ ARM flash filesystem
3637+1 records in
3638+0 records out
/var/install [2083]: +++++++++++++ ARM check filesystem
/var/install [2083]: +++++++++++++ ARM md5sum of filesystem image: f8efd2dfbbf5b3bbcc1a4336e14e7a7d  
/var/install [2083]: +++++++++++++ ARM size of filesystem image: 14897969
/var/install [2083]: +++++++++++++ ARM md5sum of filesystem mtd : f8efd2dfbbf5b3bbcc1a4336e14e7a7d  
/var/install [2083]: +++++++++++++ ARM write to /dev/mmcblk0p5 done
/var/install [2083]: +++++++++++++ ARM Calling additional procedure (ewnw_check_install)
/var/docsiscertdefaults: cm_cert.cer: in Ordnung
/var/docsiscertdefaults: cm_key_prv.bin: in Ordnung
/var/docsiscertdefaults: mfg_cert.cer: in Ordnung
/var/docsiscertdefaults: mfg_key_pub.bin: in Ordnung
/var/install [2083]: +++++++++++++ linux_fs_start = linux_fs_start    0
/var/install [2083]: +++++++++++++ linux_fs_start:     0
/var/install [2083]: +++++++++++++ set linux_fs_start=1
/var/install [2083]: +++++++++++++ set linux_fs_start = 1
/var/install [2083]: +++++++++++++ check linux_fs_start = linux_fs_start    1
/var/install [2083]: +++++++++++++ UPDATE SUCCESS
+ rc=1
+ cd /
+ test 1 -gt 1
+ test 0 -eq 1
+ exec
+ exec /var/post_install
stopping WLAN ...
sh: y: unknown operand
sh: 213: unknown operand
WLAN ... stopped
ls: /proc/1379/cwd: No such file or directory
ls: /proc/2398/cwd: No such file or directory
unmounting '/var/media/ftp/*' ..
+ ps
+ grep -v grep
+ grep -q dtrace
+ ps
  PID USER       VSZ STAT COMMAND
    1 root      1264 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW   [kworker/u:0]
    6 root         0 SW   [watchdog/0]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kworker/u:1]
   20 root         0 SW   [irq/13-arm_atom]
  100 root         0 SW   [sync_supers]
  102 root         0 SW   [bdi-default]
  104 root         0 SW<  [kblockd]
  126 root         0 SW<  [rpciod]
  127 root         0 RW   [kworker/0:1]
  133 root         0 RW   [gpio_out_bit_th]
  138 root         0 SW<  [gPunitWorkqueue]
  141 root         0 SW   [khungtaskd]
  146 root         0 SW   [kswapd0]
  147 root         0 SW   [fsnotify_mark]
  148 root         0 SW<  [nfsiod]
  150 root         0 SW<  [crypto]
  172 root         0 SW   [kapmd]
  176 root         0 SW<  [eventsink_wq]
  181 root         0 SWN  [avm_debugd]
  182 root         0 SW   [avm_event_node]
  194 root         0 SW   [kspi_bitbang_0]
  200 root         0 SW   [mtdblock0]
  206 root         0 SW   [mtdblock1]
  212 root         0 SW   [mtdblock2]
  218 root         0 SW   [mtdblock3]
  224 root         0 SW   [mtdblock4]
  230 root         0 SW   [mtdblock5]
  236 root         0 SW   [mtdblock6]
  241 root         0 SW   [kspi_bitbang_1]
  247 root         0 SW   [ACC work thread]
  256 root         0 SW   [kworker/u:2]
  258 root         0 SW   [mmcqd/0]
  275 root         0 SW   [tffsd_mtd_0]
  285 root         0 SW   [kworker/0:2]
  286 root         0 SW<  [eventsink_wq]
  287 root         0 SW   [pm_info]
  288 root         0 SW<  [eventsink_wq]
  309 root         0 SWN  [jffs2_gcd_mtd3]
  399 root         0 RW   [cleanup_timer_f]
  400 root         0 SW   [eventmapper]
  516 root         0 SW<  [capi_pipew]
  517 root         0 SW<  [capi_remote_put]
  518 root         0 RW   [pcmlink_ctrl]
  519 root         0 SW   [capitransp]
  524 root         0 RW<  [avm_dect_thread]
  625 root      1260 R    tail -f /nohup.out
  626 root      1788 S    /usr/bin/ptestd -c2
  657 root         0 SW   [flush-254:0]
  675 root      1776 S    /usr/bin/ptestd -c2
  676 root      1260 S    tail -f /var/ptestd/ptestd.log
  724 root      5744 R    /usr/sbin/pcd -f /etc/scripts/vsdk.pcd -p -t 20 -e /
  727 root      1712 S    /bin/configd
  734 root       776 S    /usr/sbin/watchdog_rt -t 10 /dev/watchdog -n
  735 root      5864 S N  /usr/sbin/logger --no-fork
  736 root      6268 S    /usr/sbin/gptimer --timer-tick=50
  851 root      5836 S    /usr/sbin/gim
  853 root      5824 S    /usr/sbin/sync_app_np_reboot
  872 root      2444 S    avmipcd
  875 root      5796 R    /usr/sbin/extswitchwatch
  879 root      2408 S    tcpproxyd
  883 root      2836 R    l2tpv3d
  908 root      8860 S    /usr/sbin/edocsis
  910 root      8508 S    /usr/sbin/upstream_manager_1q
  912 root      8860 S <  /usr/sbin/cm_status
  931 root     57988 S    /usr/sbin/hal_event_mbox
  932 root     57992 S    /usr/sbin/hal_cmd_mbox
  938 root      5800 S    /usr/sbin/docsis_bootdebug start
  941 root     58008 S    /usr/sbin/mlx -d DOCINT -n 7
  945 root     58632 R    /usr/sbin/hal_tuner_mgr
  959 root         0 SW   [flush-mtd-unmap]
  962 root         0 SW<  [cni_rx_wq]
  993 root     58004 S    /usr/sbin/qos_dsx_sm
  994 root     58160 S    /usr/sbin/dispatcher
  995 root     58148 S    /usr/sbin/docsis_mac_driver
 1017 root      2580 S    pcpd
 1049 root      3676 S    pbd
 1078 root     58012 S    /usr/sbin/downstream_manager 24 28
 1079 root     58012 S    /usr/sbin/downstream_manager 23 27
 1080 root     58012 S    /usr/sbin/downstream_manager 22 26
 1081 root     58012 S    /usr/sbin/downstream_manager 21 25
 1082 root     58012 S    /usr/sbin/downstream_manager 20 24
 1083 root     58012 S    /usr/sbin/downstream_manager 19 23
 1084 root     58012 S    /usr/sbin/downstream_manager 18 22
 1085 root     58012 S    /usr/sbin/downstream_manager 17 21
 1086 root     58012 S    /usr/sbin/downstream_manager 16 20
 1087 root     58012 S    /usr/sbin/downstream_manager 15 19
 1088 root     58012 S    /usr/sbin/downstream_manager 14 18
 1089 root     58012 S    /usr/sbin/downstream_manager 13 17
 1090 root     58012 S    /usr/sbin/downstream_manager 12 16
 1091 root     58012 S    /usr/sbin/downstream_manager 11 15
 1092 root     58012 S    /usr/sbin/downstream_manager 10 14
 1093 root     58012 S    /usr/sbin/downstream_manager 9 13
 1094 root     58012 S    /usr/sbin/downstream_manager 8 12
 1095 root     58012 S    /usr/sbin/downstream_manager 7 11
 1096 root     58012 S    /usr/sbin/downstream_manager 6 10
 1097 root     58012 S    /usr/sbin/downstream_manager 5 9
 1098 root     58012 S    /usr/sbin/downstream_manager 4 8
 1099 root     58012 S    /usr/sbin/downstream_manager 3 7
 1100 root     58012 S    /usr/sbin/downstream_manager 2 6
 1101 root     58012 S    /usr/sbin/downstream_manager 1 5
 1109 root     58024 S    /usr/sbin/upstream_manager 1 41
 1110 root     58024 S    /usr/sbin/upstream_manager 2 42
 1111 root     58024 S    /usr/sbin/upstream_manager 3 43
 1112 root     58024 S    /usr/sbin/upstream_manager 4 44
 1113 root     58024 S    /usr/sbin/upstream_manager 5 45
 1114 root     58024 S    /usr/sbin/upstream_manager 6 46
 1115 root     58024 S    /usr/sbin/upstream_manager 7 47
 1116 root     58024 S    /usr/sbin/upstream_manager 8 48
 1121 root     58940 R    /usr/sbin/snmp_agent_cm -c /etc/agent_cm.cnf -n
 1122 root     58004 S    /usr/sbin/energy_manager_app
 1123 root     58008 S    /usr/sbin/bpi_auth
 1125 root     58008 S    /usr/sbin/bpi_tek
 1126 root      8844 S    /usr/sbin/bpi_sa_map
 1142 root      1292 S    rpcbind
 1145 root      8852 S    /usr/sbin/eventmgr_cm
 1146 root      1516 S    rpc.idmapd
 1148 root     58084 S    /usr/sbin/docsis_mac_manager -x
 1162 root      9456 S    /usr/sbin/psm
 1171 root      8880 S    /usr/sbin/pacm_vendor_app
 1172 root      9904 S    /usr/sbin/pacm_snmp_agent -c /etc/agent_mta.cnf -T 3
 1173 root      9736 S    /usr/sbin/pacm_security
 1174 root      8856 S    /usr/sbin/pacm_event_mgr
 1175 root      9032 S    /usr/sbin/pacm_doim
 1184 root      9652 S    /usr/sbin/pacm_mta_control
 1295 root         0 SW   [nfsv4.0-svc]
 1343 root      1264 S    /usr/sbin/inetd
 1391 root      1568 S    /usr/bin/boxnotifyd
 1415 root       816 S    /bin/run_clock -c /dev/tffs -d
 1423 root      1264 S    sh -c echo "$0[$$]: ++++fork set_modulemen, sleep 60
 1426 root      1264 S    init
 1428 root      1252 S    sleep 600
 1456 root         0 SW   [flush-0:18]
 1797 root      3104 S    usermand
 1800 root      3024 S    contfiltd
 1939 root         0 SW   [flush-0:16]
 1940 root         0 SW   [flush-0:17]
 1941 root         0 SW   [flush-0:19]
 1942 root      1256 S    /bin/sh -c /var/post_install
 1943 root      1268 S    {exe} ash /var/post_install
 1951 root      1252 R    nc 192.168.178.2 514
 2257 root         0 SW   [flush-179:0]
 3032 root      1256 R    ps
+ echo stopping applications using ubik2/pcmlink ..
stopping applications using ubik2/pcmlink ..
+ ps
+ grep -v grep
+ grep -q capiotcp_server
+ ps
+ grep -v grep
+ grep -q telefon
+ ps
+ grep -v grep
+ grep -q dect_manager
+ ps
+ grep -v grep
+ grep -q voipd
+ sleep 2
+ ps
+ grep -v grep
+ grep -q voipd
+ lsmod
Module                  Size  Used by    Tainted: P  
userman_mod            70823  4 
edocsis_mod             4716  0 
sch_sfq                 5132  0 
sch_llq                 6791  0 
sch_tbf                 3661  0 
krtp                  137027  0 
docsis_pp             134291  0 
avalanche_cnid         33340  0 
docsis_fltr_class      26396  0 
docsis_bridge         133960  4 edocsis_mod,avalanche_cnid,docsis_fltr_class
kintr                  28773 68 
docsis_management      94250  5 docsis_fltr_class
soc_if_driver          33003  0 
kdsldmod             1404101  5 userman_mod
l2switch_proxy_driver     3964  0 
cat_l2switch_netdev     7844  1 l2switch_proxy_driver
zram                    8450  1 
lzo_compress            1823  1 zram
dect_io                10544  0 
avm_dect              233293  1 dect_io
capi_codec            356275  0 
isdn_fbox_fon5        675598  1 krtp
pcmlink               261729  4 avm_dect,capi_codec,isdn_fbox_fon5
led_modul_Fritz_Box_HW213a    88275  4 
+ echo stopping modules using ubik2/pcmlink ..
stopping modules using ubik2/pcmlink ..
+ lsmod
+ grep -q ulpcmlink
+ lsmod
+ grep -q dect_io
+ rmmod dect_io
+ lsmod
+ grep -q avm_dect
+ rmmod avm_dect
+ lsmod
+ grep -q capi_codec
+ rmmod capi_codec
+ lsmod
+ grep -q isdn_fbox_fon5
+ rmmod isdn_fbox_fon5
rmmod: can't unload 'isdn_fbox_fon5': Resource temporarily unavailable
+ sleep 2
+ lsmod
+ grep -q pcmlink
+ rmmod pcmlink
rmmod: can't unload 'pcmlink': Resource temporarily unavailable
+ set +x
still running:
  PID USER       VSZ STAT COMMAND
    1 root      1264 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW   [kworker/u:0]
    6 root         0 SW   [watchdog/0]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kworker/u:1]
   20 root         0 SW   [irq/13-arm_atom]
  100 root         0 RW   [sync_supers]
  102 root         0 SW   [bdi-default]
  104 root         0 SW<  [kblockd]
  126 root         0 SW<  [rpciod]
  127 root         0 SW   [kworker/0:1]
  133 root         0 SW   [gpio_out_bit_th]
  138 root         0 SW<  [gPunitWorkqueue]
  141 root         0 SW   [khungtaskd]
  146 root         0 SW   [kswapd0]
  147 root         0 SW   [fsnotify_mark]
  148 root         0 SW<  [nfsiod]
  150 root         0 SW<  [crypto]
  172 root         0 SW   [kapmd]
  176 root         0 SW<  [eventsink_wq]
  181 root         0 SWN  [avm_debugd]
  182 root         0 SW   [avm_event_node]
  194 root         0 SW   [kspi_bitbang_0]
  200 root         0 SW   [mtdblock0]
  206 root         0 SW   [mtdblock1]
  212 root         0 SW   [mtdblock2]
  218 root         0 SW   [mtdblock3]
  224 root         0 SW   [mtdblock4]
  230 root         0 SW   [mtdblock5]
  236 root         0 SW   [mtdblock6]
  241 root         0 SW   [kspi_bitbang_1]
  247 root         0 SW   [ACC work thread]
  256 root         0 SW   [kworker/u:2]
  258 root         0 SW   [mmcqd/0]
  275 root         0 SW   [tffsd_mtd_0]
  285 root         0 SW   [kworker/0:2]
  286 root         0 SW<  [eventsink_wq]
  287 root         0 SW   [pm_info]
  288 root         0 SW<  [eventsink_wq]
  309 root         0 SWN  [jffs2_gcd_mtd3]
  399 root         0 SW   [cleanup_timer_f]
  400 root         0 SW   [eventmapper]
  516 root         0 SW<  [capi_pipew]
  517 root         0 SW<  [capi_remote_put]
  518 root         0 RW   [pcmlink_ctrl]
  519 root         0 SW   [capitransp]
  625 root      1260 R    tail -f /nohup.out
  626 root      1788 S    /usr/bin/ptestd -c2
  657 root         0 SW   [flush-254:0]
  675 root      1776 S    /usr/bin/ptestd -c2
  676 root      1260 S    tail -f /var/ptestd/ptestd.log
  724 root      5744 R    /usr/sbin/pcd -f /etc/scripts/vsdk.pcd -p -t 20 -e /
  727 root      1712 S    /bin/configd
  734 root       776 S    /usr/sbin/watchdog_rt -t 10 /dev/watchdog -n
  735 root      5864 S N  /usr/sbin/logger --no-fork
  736 root      6268 S    /usr/sbin/gptimer --timer-tick=50
  851 root      5836 S    /usr/sbin/gim
  853 root      5824 S    /usr/sbin/sync_app_np_reboot
  872 root      2444 R    avmipcd
  875 root      5796 S    /usr/sbin/extswitchwatch
  879 root      2408 S    tcpproxyd
  883 root      2836 S    l2tpv3d
  908 root      8860 S    /usr/sbin/edocsis
  910 root      8508 S    /usr/sbin/upstream_manager_1q
  912 root      8860 S <  /usr/sbin/cm_status
  931 root     57988 S    /usr/sbin/hal_event_mbox
  932 root     57992 S    /usr/sbin/hal_cmd_mbox
  938 root      5800 S    /usr/sbin/docsis_bootdebug start
  941 root     58008 S    /usr/sbin/mlx -d DOCINT -n 7
  945 root     58632 S    /usr/sbin/hal_tuner_mgr
  959 root         0 SW   [flush-mtd-unmap]
  962 root         0 SW<  [cni_rx_wq]
  993 root     58004 S    /usr/sbin/qos_dsx_sm
  994 root     58160 S    /usr/sbin/dispatcher
  995 root     58148 S    /usr/sbin/docsis_mac_driver
 1017 root      2580 S    pcpd
 1049 root      3676 S    pbd
 1078 root     58012 S    /usr/sbin/downstream_manager 24 28
 1079 root     58012 S    /usr/sbin/downstream_manager 23 27
 1080 root     58012 S    /usr/sbin/downstream_manager 22 26
 1081 root     58012 S    /usr/sbin/downstream_manager 21 25
 1082 root     58012 S    /usr/sbin/downstream_manager 20 24
 1083 root     58012 S    /usr/sbin/downstream_manager 19 23
 1084 root     58012 S    /usr/sbin/downstream_manager 18 22
 1085 root     58012 S    /usr/sbin/downstream_manager 17 21
 1086 root     58012 S    /usr/sbin/downstream_manager 16 20
 1087 root     58012 S    /usr/sbin/downstream_manager 15 19
 1088 root     58012 S    /usr/sbin/downstream_manager 14 18
 1089 root     58012 S    /usr/sbin/downstream_manager 13 17
 1090 root     58012 S    /usr/sbin/downstream_manager 12 16
 1091 root     58012 S    /usr/sbin/downstream_manager 11 15
 1092 root     58012 S    /usr/sbin/downstream_manager 10 14
 1093 root     58012 S    /usr/sbin/downstream_manager 9 13
 1094 root     58012 S    /usr/sbin/downstream_manager 8 12
 1095 root     58012 S    /usr/sbin/downstream_manager 7 11
 1096 root     58012 S    /usr/sbin/downstream_manager 6 10
 1097 root     58012 S    /usr/sbin/downstream_manager 5 9
 1098 root     58012 S    /usr/sbin/downstream_manager 4 8
 1099 root     58012 S    /usr/sbin/downstream_manager 3 7
 1100 root     58012 S    /usr/sbin/downstream_manager 2 6
 1101 root     58012 R    /usr/sbin/downstream_manager 1 5
 1109 root     58024 S    /usr/sbin/upstream_manager 1 41
 1110 root     58024 S    /usr/sbin/upstream_manager 2 42
 1111 root     58024 S    /usr/sbin/upstream_manager 3 43
 1112 root     58024 S    /usr/sbin/upstream_manager 4 44
 1113 root     58024 S    /usr/sbin/upstream_manager 5 45
 1114 root     58024 S    /usr/sbin/upstream_manager 6 46
 1115 root     58024 S    /usr/sbin/upstream_manager 7 47
 1116 root     58024 S    /usr/sbin/upstream_manager 8 48
 1121 root     58940 S    /usr/sbin/snmp_agent_cm -c /etc/agent_cm.cnf -n
 1122 root     58004 S    /usr/sbin/energy_manager_app
 1123 root     58008 S    /usr/sbin/bpi_auth
 1125 root     58008 S    /usr/sbin/bpi_tek
 1126 root      8844 S    /usr/sbin/bpi_sa_map
 1142 root      1292 S    rpcbind
 1145 root      8852 S    /usr/sbin/eventmgr_cm
 1146 root      1516 S    rpc.idmapd
 1148 root     58084 S    /usr/sbin/docsis_mac_manager -x
 1162 root      9456 S    /usr/sbin/psm
 1171 root      8880 S    /usr/sbin/pacm_vendor_app
 1172 root      9904 R    /usr/sbin/pacm_snmp_agent -c /etc/agent_mta.cnf -T 3
 1173 root      9736 S    /usr/sbin/pacm_security
 1174 root      8856 S    /usr/sbin/pacm_event_mgr
 1175 root      9032 S    /usr/sbin/pacm_doim
 1184 root      9652 S    /usr/sbin/pacm_mta_control
 1295 root         0 SW   [nfsv4.0-svc]
 1343 root      1264 S    /usr/sbin/inetd
 1391 root      1568 S    /usr/bin/boxnotifyd
 1415 root       816 S    /bin/run_clock -c /dev/tffs -d
 1423 root      1264 S    sh -c echo "$0[$$]: ++++fork set_modulemen, sleep 60
 1426 root      1264 S    init
 1428 root      1252 S    sleep 600
 1456 root         0 SW   [flush-0:18]
 1797 root      3104 S    usermand
 1800 root      3024 R    contfiltd
 1939 root         0 SW   [flush-0:16]
 1940 root         0 SW   [flush-0:17]
 1941 root         0 SW   [flush-0:19]
 1942 root      1256 S    /bin/sh -c /var/post_install
 1943 root      1268 S    {exe} ash /var/post_install
 1951 root      1252 R    nc 192.168.178.2 514
 2257 root         0 SW   [flush-179:0]
 3107 root      1256 R    ps
Module                  Size  Used by    Tainted: P  
userman_mod            70823  4 
edocsis_mod             4716  0 
sch_sfq                 5132  0 
sch_llq                 6791  0 
sch_tbf                 3661  0 
krtp                  137027  0 
docsis_pp             134291  0 
avalanche_cnid         33340  0 
docsis_fltr_class      26396  0 
docsis_bridge         133960  4 edocsis_mod,avalanche_cnid,docsis_fltr_class
kintr                  28773 68 
docsis_management      94250  5 docsis_fltr_class
soc_if_driver          33003  0 
kdsldmod             1404101  5 userman_mod
l2switch_proxy_driver     3964  0 
cat_l2switch_netdev     7844  1 l2switch_proxy_driver
zram                    8450  1 
lzo_compress            1823  1 zram
isdn_fbox_fon5        675598  1 krtp
pcmlink               261729  2 isdn_fbox_fon5
led_modul_Fritz_Box_HW213a    88275  4 
system is going down ..
disable watchdog ...
reinit watchdog 20 sek ...
/var/post_install: start
skip deleting language from env
still running:
  PID USER       VSZ STAT COMMAND
    1 root      1264 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW   [kworker/u:0]
    6 root         0 SW   [watchdog/0]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kworker/u:1]
   20 root         0 SW   [irq/13-arm_atom]
  100 root         0 SW   [sync_supers]
  102 root         0 SW   [bdi-default]
  104 root         0 SW<  [kblockd]
  126 root         0 SW<  [rpciod]
  127 root         0 SW   [kworker/0:1]
  133 root         0 RW   [gpio_out_bit_th]
  138 root         0 SW<  [gPunitWorkqueue]
  141 root         0 SW   [khungtaskd]
  146 root         0 SW   [kswapd0]
  147 root         0 SW   [fsnotify_mark]
  148 root         0 SW<  [nfsiod]
  150 root         0 SW<  [crypto]
  172 root         0 SW   [kapmd]
  176 root         0 SW<  [eventsink_wq]
  181 root         0 SWN  [avm_debugd]
  182 root         0 RW   [avm_event_node]
  194 root         0 SW   [kspi_bitbang_0]
  200 root         0 SW   [mtdblock0]
  206 root         0 SW   [mtdblock1]
  212 root         0 SW   [mtdblock2]
  218 root         0 SW   [mtdblock3]
  224 root         0 SW   [mtdblock4]
  230 root         0 SW   [mtdblock5]
  236 root         0 SW   [mtdblock6]
  241 root         0 SW   [kspi_bitbang_1]
  247 root         0 SW   [ACC work thread]
  256 root         0 SW   [kworker/u:2]
  258 root         0 SW   [mmcqd/0]
  275 root         0 SW   [tffsd_mtd_0]
  285 root         0 SW   [kworker/0:2]
  286 root         0 SW<  [eventsink_wq]
  287 root         0 SW   [pm_info]
  288 root         0 SW<  [eventsink_wq]
  309 root         0 SWN  [jffs2_gcd_mtd3]
  399 root         0 RW   [cleanup_timer_f]
  400 root         0 SW   [eventmapper]
  516 root         0 SW<  [capi_pipew]
  517 root         0 SW<  [capi_remote_put]
  518 root         0 RW   [pcmlink_ctrl]
  519 root         0 SW   [capitransp]
  625 root      1260 R    tail -f /nohup.out
  626 root      1788 S    /usr/bin/ptestd -c2
  657 root         0 SW   [flush-254:0]
  675 root      1776 S    /usr/bin/ptestd -c2
  676 root      1260 S    tail -f /var/ptestd/ptestd.log
  724 root      5744 R    /usr/sbin/pcd -f /etc/scripts/vsdk.pcd -p -t 20 -e /
  727 root      1712 S    /bin/configd
  734 root       776 S    /usr/sbin/watchdog_rt -t 10 /dev/watchdog -n
  735 root      5864 R N  /usr/sbin/logger --no-fork
  736 root      6268 S    /usr/sbin/gptimer --timer-tick=50
  851 root      5836 S    /usr/sbin/gim
  853 root      5824 S    /usr/sbin/sync_app_np_reboot
  872 root      2444 R    avmipcd
  875 root      5796 R    /usr/sbin/extswitchwatch
  879 root      2408 R    tcpproxyd
  883 root      2836 S    l2tpv3d
  908 root      8860 S    /usr/sbin/edocsis
  910 root      8508 S    /usr/sbin/upstream_manager_1q
  912 root      8860 S <  /usr/sbin/cm_status
  931 root     57988 S    /usr/sbin/hal_event_mbox
  932 root     57992 S    /usr/sbin/hal_cmd_mbox
  938 root      5800 S    /usr/sbin/docsis_bootdebug start
  941 root     58008 S    /usr/sbin/mlx -d DOCINT -n 7
  945 root     58632 R    /usr/sbin/hal_tuner_mgr
  959 root         0 SW   [flush-mtd-unmap]
  962 root         0 SW<  [cni_rx_wq]
  993 root     58004 S    /usr/sbin/qos_dsx_sm
  994 root     58160 S    /usr/sbin/dispatcher
  995 root     58148 S    /usr/sbin/docsis_mac_driver
 1017 root      2580 S    pcpd
 1049 root      3676 S    pbd
 1078 root     58012 S    /usr/sbin/downstream_manager 24 28
 1079 root     58012 S    /usr/sbin/downstream_manager 23 27
 1080 root     58012 S    /usr/sbin/downstream_manager 22 26
 1081 root     58012 S    /usr/sbin/downstream_manager 21 25
 1082 root     58012 S    /usr/sbin/downstream_manager 20 24
 1083 root     58012 S    /usr/sbin/downstream_manager 19 23
 1084 root     58012 S    /usr/sbin/downstream_manager 18 22
 1085 root     58012 S    /usr/sbin/downstream_manager 17 21
 1086 root     58012 S    /usr/sbin/downstream_manager 16 20
 1087 root     58012 S    /usr/sbin/downstream_manager 15 19
 1088 root     58012 S    /usr/sbin/downstream_manager 14 18
 1089 root     58012 S    /usr/sbin/downstream_manager 13 17
 1090 root     58012 S    /usr/sbin/downstream_manager 12 16
 1091 root     58012 S    /usr/sbin/downstream_manager 11 15
 1092 root     58012 S    /usr/sbin/downstream_manager 10 14
 1093 root     58012 S    /usr/sbin/downstream_manager 9 13
 1094 root     58012 S    /usr/sbin/downstream_manager 8 12
 1095 root     58012 S    /usr/sbin/downstream_manager 7 11
 1096 root     58012 S    /usr/sbin/downstream_manager 6 10
 1097 root     58012 S    /usr/sbin/downstream_manager 5 9
 1098 root     58012 S    /usr/sbin/downstream_manager 4 8
 1099 root     58012 S    /usr/sbin/downstream_manager 3 7
 1100 root     58012 S    /usr/sbin/downstream_manager 2 6
 1101 root     58012 R    /usr/sbin/downstream_manager 1 5
 1109 root     58024 S    /usr/sbin/upstream_manager 1 41
 1110 root     58024 S    /usr/sbin/upstream_manager 2 42
 1111 root     58024 S    /usr/sbin/upstream_manager 3 43
 1112 root     58024 S    /usr/sbin/upstream_manager 4 44
 1113 root     58024 S    /usr/sbin/upstream_manager 5 45
 1114 root     58024 S    /usr/sbin/upstream_manager 6 46
 1115 root     58024 S    /usr/sbin/upstream_manager 7 47
 1116 root     58024 S    /usr/sbin/upstream_manager 8 48
 1121 root     58940 S    /usr/sbin/snmp_agent_cm -c /etc/agent_cm.cnf -n
 1122 root     58004 S    /usr/sbin/energy_manager_app
 1123 root     58008 S    /usr/sbin/bpi_auth
 1125 root     58008 S    /usr/sbin/bpi_tek
 1126 root      8844 S    /usr/sbin/bpi_sa_map
 1142 root      1292 S    rpcbind
 1145 root      8852 S    /usr/sbin/eventmgr_cm
 1146 root      1516 S    rpc.idmapd
 1148 root     58084 S    /usr/sbin/docsis_mac_manager -x
 1162 root      9456 S    /usr/sbin/psm
 1171 root      8880 S    /usr/sbin/pacm_vendor_app
 1172 root      9904 R    /usr/sbin/pacm_snmp_agent -c /etc/agent_mta.cnf -T 3
 1173 root      9736 S    /usr/sbin/pacm_security
 1174 root      8856 S    /usr/sbin/pacm_event_mgr
 1175 root      9032 S    /usr/sbin/pacm_doim
 1184 root      9652 S    /usr/sbin/pacm_mta_control
 1295 root         0 SW   [nfsv4.0-svc]
 1343 root      1264 S    /usr/sbin/inetd
 1391 root      1568 S    /usr/bin/boxnotifyd
 1415 root       816 R    /bin/run_clock -c /dev/tffs -d
 1423 root      1264 S    sh -c echo "$0[$$]: ++++fork set_modulemen, sleep 60
 1426 root      1264 S    init
 1428 root      1252 S    sleep 600
 1456 root         0 SW   [flush-0:18]
 1797 root      3104 R    usermand
 1800 root      3024 R    contfiltd
 1939 root         0 SW   [flush-0:16]
 1940 root         0 SW   [flush-0:17]
 1941 root         0 SW   [flush-0:19]
 1942 root      1256 S    /bin/sh -c /var/post_install
 1943 root      1268 S    {exe} ash /var/post_install
 1951 root      1252 R    nc 192.168.178.2 514
 2257 root         0 SW   [flush-179:0]
 3118 root      1256 R    ps
Module                  Size  Used by    Tainted: P  
userman_mod            70823  4 
edocsis_mod             4716  0 
sch_sfq                 5132  0 
sch_llq                 6791  0 
sch_tbf                 3661  0 
krtp                  137027  0 
docsis_pp             134291  0 
avalanche_cnid         33340  0 
docsis_fltr_class      26396  0 
docsis_bridge         133960  4 edocsis_mod,avalanche_cnid,docsis_fltr_class
kintr                  28773 68 
docsis_management      94250  5 docsis_fltr_class
soc_if_driver          33003  0 
kdsldmod             1404101  5 userman_mod
l2switch_proxy_driver     3964  0 
cat_l2switch_netdev     7844  1 l2switch_proxy_driver
zram                    8450  1 
lzo_compress            1823  1 zram
isdn_fbox_fon5        675598  1 krtp
pcmlink               261729  2 isdn_fbox_fon5
led_modul_Fritz_Box_HW213a    88275  4

Kann jemand erkennen, was falsch gelaufen ist? Ich möchte es ungern noch einmal versuchen, bevor ich Hilfe bekommen habe.
Wie kann ich das FS1 wieder herstellen?

 

[Fritz2016]

Hallo criens,

kann es sein, dass das Branding weiterhin auf KDG steht?

Mich wundert es, dass du ohne probleme auf 6.50 booten kannst. Wie ich aus diesem Thread verstanden habe, bootet 6.50 von KDG nur bei kdg branding.

Wobei lt. Log wird eigentlich getestet, ob das Branding AVM ist.

 

[criens]

Bei 6.50 habe ich noch das kdg Branding drauf

 

[PeterPawn]

Ein "mismatch" beim Branding kann eigentlich nur dann auftreten (ich hatte deutlich darauf hingewiesen, daß "autoupdate" auf der 6490 meinerseits nicht getestet wurde), wenn zum Zeitpunkt des Vergleichs die OEM-Variable für das aktuelle Brandings nicht gesetzt ist: https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/run_update#L164 - dann wird eben "avm" angenommen, wie das auch in der "rc.conf" von AVM beim Start der Box der Fall ist:

# cat /etc/init.d/rc.conf
export CONFIG_OEM_DEFAULT="avm"
[...]
##########################################################################################
## OEM Ermitteln
##########################################################################################
OEM_tmp=`cat $CONFIG_ENVIRONMENT_PATH/firmware_version`
if [ -z "${OEM_tmp}" ] ; then
OEM_tmp=$CONFIG_OEM_DEFAULT
fi
OEM=${OEM_tmp%,*}
OEM_DEFAULT_INDEX=${OEM_tmp#*,}
if [ "$OEM_DEFAULT_INDEX" = "$OEM" ] ; then
OEM_DEFAULT_INDEX=""
fi
export OEM_DEFAULT_INDEX
export OEM

Wenn also kein OEM gesetzt ist, kommt "CONFIG_OEM_DEFAULT" zum Einsatz und das ist normalerweise "avm".

Allerdings erinnert mich das daran, daß es ja auch bei der Ausführung von "post_install" ganz deutlich ein paar fehlende Environment-Variablen gibt, denn die Zeilen

+ exec /var/post_install
stopping WLAN ...
[COLOR="#FF0000"]sh: y: unknown operand
sh: 213: unknown operand
[/COLOR]WLAN ... stopped

sind ja auf das Fehlen zweier anderer Variablen zurückzuführen.

Solange die Ursache dieser fehlenden Variablen nicht klar ist, ist es auf der 6490 vielleicht keine gute Idee, einfach auf "avm" zu wetten ... man kann den aktuell eingestellten Wert ja noch einmal aus der Box auslesen, wenn $OEM tatsächlich leer ist. Daß es dann beim Wechsel des Branding Probleme geben könnte, wenn die Variablen fehlen, steht schon hier: http://www.ip-phone-forum.de/showthread.php?t=286994&p=2189036&viewfull=1#post2189036

Wenn ich nachher lustig bin, werde ich mal einen zusätzlichen Versuch der Informationsbeschaffung einbauen, wenn $OEM leer ist.

- - - Aktualisiert - - -

Na gut, war nur eine zusätzliche Zeile ... wenn am Ende in /proc/sys/urlader/environment auch kein Branding steht, kann ich es nicht ändern.

 

[PeterPawn]

@opto:
Das kannst Du leicht selbst überprüfen ... wenn Du von extern auf einer Box das GUI aufrufst und dann oben rechts auf "FRITZ!NAS" gehst, kriegst Du ein Redirect auf den Port, der an den x86-Core weitergeleitet wird.

Wenn Du von extern eine Datei auf Deine FRITZ!Box übertragen willst, ist das für die Download und da sollte der PA eigentlich greifen ... ich wüßte nicht, warum die .254 (oder welche auch immer das ist, hängt ja von der LAN-Konfiguration ab) da anders behandelt werden müßte oder sollte als irgendein anderer Host im LAN.

Selbst wenn man von extern "downloaden" will und das aus Sicht der Box Upstream ist, hat die Box ja immer noch nur eine einzige externe Adresse (im Normalfall jedenfalls) und wenn man dann auf das zweite System will (wo ja der NAS arbeitet), dann kann das ja nicht über den im GUI des ARM-Core eingestellten Port funktionieren (ohne den erwähnten Reverse-Proxy) und soweit ich das überblicke, gibt es keine gesonderte GUI-Einstellung für den HTTPS-Port auf dem ATOM-Core. Das mit dem PA, der dann greifen sollte, gilt auch m.E. tatsächlich nur für den Downstream der Box - aber das Übertragen eines Backups vom eigenen "dedicated server" wäre z.B. ein solches Szenario, wo das ein sehr angenehmer Nebeneffekt ist.

Am Ende ist das sogar um einiges schneller, wenn man das per TLS-gesicherter HTTP-Verbindung über den (schnelleren und doppelten) x86-Core macht, als wenn man sich mit IPSec auf den ARM-Core verbindet und dort die Prozessorpower schon viel früher am Anschlag ist.

Ansonsten habe ich auch nichts davon geschrieben, daß die FRITZ!Box ein vollwertiger SAT>IP-Server wäre ... die Diskussion haben wir schon fast zwei Jahre (und an der Implementierung hat sich für mich nichts entscheidendes geändert), auch hier in irgendeinem Thread. Daher schrieb ich auch von "SAT>IP-Unterstützung" und die kannst Du nicht leugnen:

# wget -qO -  http://192.168.178.254:49000/satipdesc.xml
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0" configId="0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:ses-com:device:SatIPServer:1</deviceType>
<friendlyName>FRITZ!Box 6490 Cable</friendlyName>
<manufacturer>AVM Berlin</manufacturer>
<manufacturerURL>http://www.avm.de</manufacturerURL>
<modelDescription>FRITZ!Box 6490 Cable</modelDescription>
<modelName>FRITZ!Box 6490 Cable</modelName>
<modelNumber>avm</modelNumber>
<modelURL>http://www.avm.de</modelURL>
<serialNumber></serialNumber>
<UDN>uuid:663d5d6c-f9f8-4bb4-84d4-C80E14AFA493</UDN>
<iconList>
</iconList>
<serviceList>
<service>
<serviceType>urn:ses-com:service:satip:1</serviceType>
<serviceId>urn:ses-com:serviceId:satip</serviceId>
<controlURL>/upnp/control/satip</controlURL>
<eventSubURL>/upnp/control/satip</eventSubURL>
<SCPDURL>/satipSCPD.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>http://192.168.178.254</presentationURL>
<satip:X_SATIPCAP xmlns:satip="urn:ses-com:satip">DVBC-2</satip:X_SATIPCAP>
</device>
</root>

Ich wollte auch weder die Qualität noch die Kompatibilität der SAT>IP-Unterstützung in der 6490 thematisieren, sondern nur ein anderes Beispiel für eine noch sehr unvollständige Dokumentation seitens AVM anführen. Da ich mir andere Bereiche der Dokumentation meist nicht näher ansehe (jedenfalls nicht ohne triftigen Grund), mag es noch weitere Stellen geben, die ähnlich schlecht "versorgt" sind.

 

[fesc]

@opto: Ich weiss nicht ob das was damit zu tun hat, aber man kann generell ueber das web-interface keine forwarding rule / freigabe auf die.254 (atom) adresse erstellen (wird abgelehnt, was ja auch Sinn macht).
Wenn man aber auf dem Atom ein virtuelles interface (z.b. lan:1 = .253) erstellt und dahin dann eine forwarding rule definiert dann geht es, und man wuerde auch an den dvb stream kommen.

 

[PeterPawn]

Bei IPv6 hat die Box ja auch extern die Chance, auf eine andere IPv6-Adresse unterhalb des eigenen Präfix weiterzuleiten ... da geht bei IPv4 aber nicht. Meine Schilderung der Weiterleitung bezog sich auf IPv4. Aber auch für die IPv6-Kommunikation muß es ja auch dem ARM-Core ein Routing geben und da kann dann tatsächlich auch extern wieder derselbe Port verwendet werden, wie für den ARM-Core beim (externen) GUI - ist halt ein anderer Host und eine "vollständige Adresse" besteht immer aus der IPvX-Adresse und einer Port-Nummer (bei L4(+)-Protokollen mit Ports) für den "endpoint".

Da das DVB-Streamen aus der Sicht der Box eben Upstream ist, sehe ich nur wenige Chancen, das hinzubekommen - solange da nicht auch der Upstream "beschleunigt" werden kann. Ein HD-Stream aus dem DVB-C-Signal müßte ansonsten erst wieder vom ATOM-Core durch den ARM-Core an das eCM gelangen ... d.h. der ARM-Core hat zu schindern und (meine Meinung, aber ungetestet) wird eher nicht hinterherkommen. Ein Transcoding fällt sicherlich auch aus (schon TS-Demuxen dürfte auf dem x86-Core in Hardware erfolgen) und damit sind gerade VBR-Streams für so einen Upload ein echtes Risiko.

 

[tetzlav]

Bei 6.50 habe ich noch das kdg Branding drauf

Dann setze das branding auf "avm", denn in der installierten Retail-Firmware ist kein kdg-branding enthalten...

 

[Pokemon20021]

curr: 141.06.50  new: xx.06.63
debug: curr: 141.06.50
debug: new: "XX.06.63"
major_currFWver=141
middle_currFWver=6 
minor_currFWver=50
middle_newFWver=6
minor_newFWver=63
check Firmware Version: xx.06.63
DEBUG: 6 >= 6
DEBUG: 63 >= 50
Accept Firmware Version: xx.06.63

Kann jemand erkennen, was falsch gelaufen ist?

Seltsam, da steht "Firmware Version: xx.06.63"
eigentlich sollte da 141.06.63 stehen ?
ist das eine gemoddete Firmware-Version ?
wenn ja was wurde geändert ?

 

[tetzlav]

@Pokemon20021: das ist die Debug-Ausgabe aus der original AVM install (Zeile 238ff) und "normal".

##################################################################################
currFWver=`/etc/version -v`
echo "curr: ${currFWver}  [COLOR=#ff0000]new: xx.${newFWver}[/COLOR]"
# Version AA.BB.CC zerlegen
major_currFWver=${currFWver%%.*} # bis zum ersten Punkt
middle_currFWver=${currFWver%.*}; middle_currFWver=${middle_currFWver#*.} # dazwischen
minor_currFWver=${currFWver##*.} # ab dem letzten Punkt
echo "debug: curr: ${major_currFWver}.${middle_currFWver}.${minor_currFWver}"
middle_newFWver=${newFWver%.*}; middle_newFWver=${middle_newFWver#*.} # dazwischen
minor_newFWver=${newFWver##*.} # ab dem letzten Punkt
echo "debug: [COLOR=#ff0000]new: \"XX.${middle_newFWver}.${minor_newFWver}[/COLOR]\""
##################################################################################

 

[tetzlav]

Bei 6.50 habe ich noch das kdg Branding drauf

Dann setze das branding auf "avm", denn in der installierten Retail-Firmware ist kein kdg-branding enthalten...

Wenn sich @criens nicht mehr meldet scheints wohl einfach nur das falsche branding gewesen zu sein?! Sonst wäre bestimmt nochmal was gekommen...

 

[PeterPawn]

Ich mußte jetzt beim Testen einer neuen Lösung mehrmals Fehler in einem unausgereiften SquashFS-Image auf dem ARM-Core korrigieren und dabei ging es mir dann irgendwann auf den Zeiger, immer erst auf das andere System umzuschalten, um dann von dort aus einer SSH-Session die inaktive Partition mit dem korrigierten System zu beschreiben - das System in der anderen Partition wollte ich nicht überschreiben, daher kam "immer abwechselnd" nicht wirklich in Frage.

Also habe ich es einfach einmal versucht, auch die aktive Partition zu beschreiben ... natürlich macht das nur dann Sinn, wenn man danach unmittelbar die Box neu startet und zwar auf die denkbar härteste Art und Weise - wie sich weitere Zugriffe auf die mmcblk-Partition auswirken, kann man schlecht vorhersehen.

Es sollte möglichst nicht mehr zum Lesen irgendwelcher Dateien aus dem (alten) SquashFS-Image kommen (gut, gäbe vermutlich auch nur eine "kernel panic", wenn etwas nicht zu dekomprimieren ist) - daher habe ich das neue Dateisystem (es ging nur noch um ein einzelnes System - das andere sollte unverändert bleiben und ich glaube auch nicht, daß das für beide Systeme zusammen funktioniert - habe ich aber nicht probiert mangels Notwendigkeit) von /var/media/ftp, worüber ich das jeweils auf die Box gebracht habe, nach /var/tmp kopiert, bevor ich es in die mmcblk-Partition schreiben ließ.

Im Anschluß noch (mehr pro forma, aber das ext4-FS unter /var/media/ftp ist ja noch aktiv und kann das vielleicht brauchen, wobei das eher für das x86-System wichtig wäre, das ARM-System greift ja nur über NFS dort zu) ein "sync" für die Dateisysteme und dann ein "reboot" - das aber alles nicht als "normale" Kommandos, sondern direkt über "sysrq-trigger". Vorher schon alle nicht notwendigen Dienste stoppen, dabei kann einem das "prepare_fwupgrade" dann auch mal sinnvoll helfen - entscheidender ist das Entladen von gemounteten USB-Volumes, weil die sonst ggf. am Ende "dirty" sind.

Das sieht dann in etwa so aus:

# [COLOR="#0000FF"]prepare_fwupgrade start UPNP[/COLOR]
[...] jede Menge Text beim Herunterfahren der Dienste
# [COLOR="#0000FF"]rpc sync[/COLOR] -> auf dem anderen System die Buffer leeren
# [COLOR="#0000FF"]dd if=/var/tmp/... of=/dev/mmcblk0p... bs=$(stat -c %s /var/tmp/...)[/COLOR] -> "auf einen Rutsch schreiben", um Blöcke kümmert sich der eMMC-Treiber
# [COLOR="#0000FF"]echo s > /proc/sysrq-trigger[/COLOR] -> sync filesystems
# [COLOR="#0000FF"]echo b > /proc/sysrq-trigger[/COLOR] -> hard reboot

Anschließend startet die Box dann neu, ohne irgendwelche weiteren sichtbaren Reaktionen in der Shell-Session - nicht einmal die TCP-Verbindung wird "richtig" geschlossen.

Sicherlich nicht die feine englische Art, aber erstens sparte es mir beim Korrigieren von Fehlern im Image einiges an Zeit, weil die ständige Umschaltung und der Neustart des alternativen Systems entfielen und zweitens wäre das wieder ein Weg für einen Angreifer (der sein neues Image direkt auf der Box aufbereitet und dazu das aktive System einfach als Template benutzt - wobei man das Packen auch als berechtigter User besser nur auf dem x86-Core machen läßt, es ist einfach viel schneller), das System ohne größere Spuren zu hinterlassen zu verändern.

Wer denkt bei irgendeinem unmotivierten Neustart schon als erstes daran, daß da vielleicht ein Wurm oder ähnliches soeben das System infiziert hat ... also besser auf der Hut sein und nicht einfach mit einem Schulterzucken reagieren, wenn die Box ohne erkennbaren Grund neu startet oder zumindest im Nachhinein nachschauen, was nun die Ursache war (steht bei einem "echten Absturz" im Crash-Log in den Supportdaten - aber nicht beim Triggern über SysRq).

 

[cable-helper]

Eine kurze Entführung des Threads dahingehend, das es nun Klarheiten gibt, was die Thematiks des Herstellerzertifikats angeht, welche in dem Thread angesprochen wurde:

c't berichtet: https://www.heise.de/ct/ausgabe/2016-24-AVM-entweicht-geheimer-Krypto-Schluessel-3459813.html

 

[jojo-schmitz]

Demnach dürfte es wohl demnächst ein FW Upgrade über die Provider geben?