[Info] FRITZ!Box-Hardware "Spezialtabelle" - (Nicht immer) brandaktuell!

Die "Höcker" sind der ersten 7390 geschuldet, deren WLAN-Antennen als Paddel auf die Platine aufgesetzt waren. Bei der 7490 war das irgendwann nur noch ein Paddel (aus der Erinnerung).
 
@PeterPawn

Hast du eventuell einen Link zu Tuts wie ich mir den Zugang schaffe? Bin nochnicht so firm bei FBs. Meine derzeitige 7490 war meine erste FB, an der ich aber nochnichts geändert habe. Bin gerade mal froh, das ich diese mit dem Fritzfon C4 und ner stabilen VPN eingerichtet bekommen hab.
 
Zuletzt bearbeitet:
Eine Schwachstelle ist ganz simpel auszunutzen, siehe in meinem GitHub-Repository unter YourFritz/reported_threats/79irgendwas. Braucht kein Tutorial - wird's auch von mir nicht geben, ist ohnehin in der nächsten Version bereits geschlossen.
 
Ui, das muss ich erst einmal finden. Will nicht sagen, das ich ein Noob bin, aber ich bin wohl noch vom DD-WRT sehr verwöhnt. Kannst du mir erklären, wie ich dein " GitHub-Repository unter YourFritz/reported_threats/79..." finden kann?
 
haha :D
Google ist dein Freund!

naja BTT: AR9381, QCA9882.. irgendwie nicht so auf dem neusten Stand, oder?
Absicht? Oder kosten die Wave2 Chips so viel mehr?
 
UI

@ PeterPawn

Mit deiner Hilfe konnte ich mich auf der betreffenden Seite einfinden.
Aber da hört es schon auf. Mit den Files weis ich sogut wie nichts anzufangen.
Linux ist wohl doch nicht so meins.

Wenn sich mal ein Tut auffinden sollte, so werde ich mich mal daran machen.

Danke vorerst.
 
Zuletzt bearbeitet:
Leider habe ich es nicht geschafft, etwas zu finden wie ich auf die Shell komme. Ich gebs einfach auf. Werde die box einfach gegen eine 7490 tauschen. So weis ich, das bei einem Ausfall bedingten Wechsel wieder alles wie gewohnt funktieniert. Die FB 7560 will ich nicht durch irgendwelche Experimente aufs Spiel setzen.
 
Hier noch ein paar Sachen zur Fritz!Box 4040, die ich in der Laborfirmware gefunden habe: in

[FONT=&amp]var/install[/FONT][FONT=&amp]:



arm_32MB_cortexa9_5geth_usb_host_usb_host3_2wlan11n_61414



[/FONT]
[FONT=&amp]kernel_start=0x00220000[/FONT]
[FONT=&amp]kernel_size=31326208[/FONT]
[FONT=&amp]filesystem_start=0x02000000[/FONT]
[FONT=&amp]filesystem_size=0[/FONT]
[FONT=&amp]urlader_start=0x00000000[/FONT]
[FONT=&amp]urlader_size=1179648[/FONT]
[FONT=&amp]newFWver=06.69[/FONT]
[FONT=&amp]flash_start=0[/FONT]
[FONT=&amp]# Versioninfo:[/FONT]
[FONT=&amp]155.06.69-43367 (Labor)[/FONT]
[FONT=&amp]# Buildnummer:[/FONT]
[FONT=&amp]r43367[/FONT]
[FONT=&amp]# Checkpoint:[/FONT]
[FONT=&amp]r36142


[/FONT]
Analyse des kernel.image:[FONT=&amp]

[/FONT]
[FONT=&amp]binwalk kernel.image [/FONT]

[FONT=&amp]DECIMAL HEXADECIMAL DESCRIPTION[/FONT]
[FONT=&amp]--------------------------------------------------------------------------------[/FONT]
[FONT=&amp]2382080 0x245900 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 18099913 bytes, 4695 inodes, blocksize: 65536 bytes, created: 1970-07-29 11:45:13[/FONT]

Extraktion des enthaltenen squashfs images:

[FONT=&amp]dd if=kernel.image bs=1 skip=2382080 count=18099913 of=image.squashfs[/FONT][FONT=&amp]
[/FONT]

[FONT=&amp]Entpacken des [/FONT]squashfs images [FONT=&amp]mittels [/FONT]unsquashfs:

[FONT=&amp]unsquashfs image.squashfs
[/FONT]

In squashfs-root/etc/version findet sich dann z.B.:

[FONT=&amp]export FIRMWARE_VERSION=${CONFIG_VERSION_MAJOR}.06.69
export FIRMWARE_SUBVERSION="-43367"
export FIRMWARE_DATE="23.02.2017 09:07:14"

[/FONT]
[FONT=&amp]#########################################################[/FONT]
[FONT=&amp]BUILD=0.1[/FONT]
[FONT=&amp]TI_VER=3.3.0[/FONT]
[FONT=&amp]BOARD=AR7RD[/FONT]
[FONT=&amp]FSSTAMP=20170223090714[/FONT]

[FONT=&amp]#########################################################[/FONT]

Busybox:
[FONT=&amp]
[/FONT]
[FONT=&amp]BusyBox v1.22.1 (2016-12-05 11:08:55 CET)

[/FONT]
[FONT=&amp]strings gefunden in busybox u.a.:[/FONT][FONT=&amp]

[/FONT]
[FONT=&amp]/GU/archiv/tmp-cortexa9-gcc_x86_64/usr/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.8.3/include[/FONT][FONT=&amp]
/GU/archiv/tmp-cortexa9-gcc_x86_64/usr/build/linux-headers-3.10.53/usr/include/linux
[/FONT]

Aus
etc/init.d/rc.conf:

##########################################################################################
## Box spezifische Konfiguration (aus Produkt.init)
##########################################################################################
export CONFIG_ANNEX="Ohne"
export CONFIG_INSTALL_TYPE="arm_32MB_cortexa9_5geth_usb_host_usb_host3_2wlan11n_61414"
export CONFIG_VERSION="06.69"
export CONFIG_SUBVERSION="-43367"
export CONFIG_VERSION_MAJOR="155"
export CONFIG_ROMSIZE="0-sflash_size=32MB-nand_size=0"
export CONFIG_RAMSIZE="256"
export CONFIG_RELEASE="2"
export CONFIG_BETA_RELEASE="1"
export CONFIG_LABOR_ID_NAME="BETA"
export CONFIG_BUILDTYPE="1001"
export CONFIG_BUILDNUMBER="43367"

ls -1 lib32/modules/

3.14.43
3.14.43+
6320_Default_EEPROM.bin
6842F1_Default_EEPROM.bin
eeprom_db120
eeprom_k2
eeprom_kiwi_7412_B1
eeprom_osprey
eeprom_peacock
eeprom_peregrine
eeprom_scorpion2g
eeprom_wasp
pm_info.in
 
Zuletzt bearbeitet:
Weiß jemand welche HW-Revision die 6430 Cable besitzt? Oder hat jemand ein Firmware-Image zu dieser?

Meines Erachtens kommt für die 6430 eigentlich nur HW-Rev. 214, 216 oder 222 in Frage.

Edit:
Die Ausgabe von z.B. "cat /proc/mtd" u.a. bei den Modellen 7560 und 7580 wäre interessant.





Ist anhand der ICs deinerseits etwas über die Taktrate der CPU zu sagen?
Bei der 7560 max. 600MHz, bei der 7580 max. 1.000MHz und bei der 7590 noch unbekannt (max. 1.000MHz oder vielleicht auch 1.200MHz, mal sehen):
Code:
cpuclocks {
	compatible = "lantiq,scaling-frequencies";

	xrx350_cpuclocks: cpuclocks@0 {
		status = "disabled";
		lantiq,cpuclocks = <600000000 300000000 200000000 200000000>;
		lantiq,ddrclocks = <333000000 333000000 166000000 166000000>;
		lantiq,threshold_dp = <1 1 1 101>;
		lantiq,poll_period = <11>;
	}; 

	xrx550_800_cpuclocks: cpuclocks@1 {
		status = "disabled";
		lantiq,cpuclocks = <800000000 600000000 300000000 200000000>;
		lantiq,ddrclocks = <333000000 333000000 166000000 166000000>;
		lantiq,threshold_dp = <1 1 1 101>;
		lantiq,poll_period = <11>;
	}; 

	xrx550_1000_cpuclocks: cpuclocks@2 {
		status = "disabled";
		lantiq,cpuclocks = <1000000000 666666666 333333333 200000000>;
		lantiq,ddrclocks =  <400000000 333000000 333000000 333000000>;
		lantiq,threshold_dp = <1 1 1 101>;
		lantiq,poll_period = <11>;
	};
	
	xrx550_1200_cpuclocks: cpuclocks@3 {
		status = "disabled";
		lantiq,cpuclocks = <1200000000 800000000 300000000 200000000>;
		lantiq,ddrclocks =  <400000000 333000000 333000000 333000000>;
		lantiq,threshold_dp = <1 1 1 101>;
		lantiq,poll_period = <11>;
	};
};
Quelle: ftp://ftp.avm.de/fritz.box/fritzbox.7580/x_misc/opensrc/source-files-FRITZ.Box_7580-06.81.tar.gz (xrx500.dtsi)


Habe nur herrausgefunden, das es eine GRX350 Intel AnyWan CPU ist.
Und der kommt wohl bei der 7560 als auch bei der 7580 zum Einsatz und wahrscheinlich auch bei der 7590:
Code:
model = "AVM7560 (GRX350, HW221) Main model"
Quelle: ftp://ftp.avm.de/fritz.box/fritzbox.7580/x_misc/opensrc/source-files-FRITZ.Box_7580-06.81.tar.gz (Fritz_Box_HW221.dts)

Code:
model = "AVM7580 (GRX350, HW225) Main model"
Quelle: ftp://ftp.avm.de/fritz.box/fritzbox.7580/x_misc/opensrc/source-files-FRITZ.Box_7580-06.81.tar.gz (Fritz_Box_HW225.dts)

Code:
model = "AVM7590 (GRX350, HW226) Main model"
Quelle: ftp://ftp.avm.de/fritz.box/fritzbox.7580/x_misc/opensrc/source-files-FRITZ.Box_7580-06.81.tar.gz (Fritz_Box_HW226.dts)
 
Zuletzt bearbeitet:
Die Ausgabe von z.B. "cat /proc/mtd" u.a. bei den Modellen 7560 und 7580 wäre interessant.
Code:
# [COLOR="#0000FF"][B]cat /proc/mtd[/B][/COLOR]
dev:    size   erasesize  name
mtd0: 00800000 00040000 "kernel"
mtd1: 00100000 00040000 "urlader"
mtd2: 00400000 00040000 "nand-tffs"
mtd3: 00800000 00040000 "reserved-kernel"
mtd4: 1eb00000 00040000 "ubi"
mtd5: 02c0d000 0003f000 "filesystem"
mtd6: 02c0d000 0003f000 "reserved-filesystem"
mtd7: 00237000 0003f000 "config"
mtd8: 17e2f000 0003f000 "nand-filesystem"
# [COLOR="#0000FF"][B]ubinfo -a[/B][/COLOR]
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

ubi0
Volumes count:                           4
Logical eraseblock size:                 258048 bytes, 252.0 KiB
Total amount of logical eraseblocks:     1960 (505774080 bytes, 482.3 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       4
Count of reserved physical eraseblocks:  36
Current maximum erase counter value:     3
Minimum input/output unit size:          4096 bytes
Character device major/minor:            244:0
Present volumes:                         0, 1, 2, 3

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        179 LEBs (46190592 bytes, 44.1 MiB)
State:       OK
Name:        avm_filesys_0
Character device major/minor: 244:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        179 LEBs (46190592 bytes, 44.1 MiB)
State:       OK
Name:        avm_filesys_1
Character device major/minor: 244:2
-----------------------------------
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        9 LEBs (2322432 bytes, 2.2 MiB)
State:       OK
Name:        avm_config
Character device major/minor: 244:3
-----------------------------------
Volume ID:   3 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        1553 LEBs (400748544 bytes, 382.2 MiB)
State:       OK
Name:        avm_userdata
Character device major/minor: 244:4
# [COLOR="#0000FF"][B]grep Product /proc/sys/urlader/environment[/B][/COLOR]
ProductID       [COLOR="#FF0000"][B]Fritz_Box_HW225[/B][/COLOR]
 
Dankeschön! Ist das von linux_fs_start=1 ausgehend?

Damit konnten nun jedenfalls für die 7580 alle Fragezeichen entfernt werden (zumindest die Tabelle betreffend ;)).

Vielleicht wäre es sinnvoll in Zukunft zusätzliche Informationen bzgl. der verwendeten Dateisysteme und Kernelversionen in die Tabelle zu integrieren? Wobei das ja eigentlich nicht mehr viel mit Hardware zu tun hat (allerdings sind schon einige grundlegende Informationen bzgl. der Firmware enthalten), vielleicht auch mal eine separate Tabelle dafür anfangen...
 
Nein, ist im Moment "linux_fs_start=0". mtd5 enthält eine 06.54 (noch die originale, die bei Auslieferung schon drin war) und mtd6 (hier inaktiv, daher "reserved") enthält die 06.81 mit "modfs"-Anpassungen.

Die 7580 ist tatsächlich (aus Software-Sicht) nicht uninteressant und trotz ihres älteren Kernels teilweise "weiter", als die VR9-Modelle.
Code:
root@FB7490:~ $ [COLOR="#0000FF"][B]cat /proc/filesystems[/B][/COLOR]
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   tmpfs
nodev   devtmpfs
nodev   debugfs
nodev   securityfs
nodev   sockfs
nodev   pipefs
nodev   anon_inodefs
nodev   configfs
nodev   devpts
        ext3
        ext2
        ext4
        squashfs
nodev   ramfs
        fuseblk
nodev   fuse
nodev   fusectl
        yaffs
        yaffs2
nodev   mqueue
nodev   mtd_inodefs
nodev   ubifs
Code:
root@FB7580:~ $ [COLOR="#0000FF"][B]cat /proc/filesystems[/B][/COLOR]
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   tmpfs
nodev   devtmpfs
nodev   debugfs
nodev   sockfs
nodev   pipefs
nodev   anon_inodefs
nodev   rpc_pipefs
nodev   devpts
        ext3
        ext2
        ext4
        squashfs
nodev   ramfs
        msdos
nodev   [COLOR="#FF0000"][B]nfs[/B][/COLOR]
nodev   [COLOR="#FF0000"][B]autofs[/B][/COLOR]
        fuseblk
nodev   fuse
nodev   fusectl
nodev   [COLOR="#FF0000"][B]overlayfs[/B][/COLOR]
[COLOR="#FF0000"][B]        xfs
[/B][/COLOR]nodev   mqueue
nodev   mtd_inodefs
nodev   ubifs
Was ich noch nicht verstanden habe, sind die Pläne, die AVM mit der 2 MB-Partition unter "config" nun haben mag ... bei der 7490 war die ja wenigstens noch unter "/var/flash" gemountet und die "character devices" für die TFFS-Nodes sind damit "semi-permanent" und man kann sie z.B. durch reguläre Dateien ersetzen. Bei der 7580 liegt dann "/var/flash" wieder im "tmpfs" und die Nodes werden bei jedem Start dort angelegt. Zumindest könnte man damit diese Partition wohl wieder für die Speicherung eigener Daten benutzen, die sich beide Systeme teilen können (und die auch ein Update überleben) und die trotzdem dem Zugriff über die NAS-Funktionen entzogen sind - wenn die zwei MB zuwenig sind, kann man notfalls die Aufteilung des Speichers im UBI-Device noch ändern.

Ich hätte ja erwartet, daß AVM da selbst Daten ablegt (z.B. die Updates der BPjM-Liste), auf die der Benutzer keinen Zugriff haben sollte ... mit der (zumindest theoretisch) verfügbaren Kompression (zlib oder LZO) bei der Verwendung von UBIFS sollte es da auch möglich sein, etwas mehr als 2 MB zu speichern, solange es halbwegs komprimierbar ist.

Das ist auch eines der Fragezeichen, die ich noch habe ... der interne NAND-Flash für das NAS ist bei AVM als UBIFS gemountet; ich weiß aber noch nicht, ob mit Kompression oder ohne (beim Mount-Kommando sieht man nichts, man muß also in die Kernel-Quellen eintauchen). Wenn da wirklich immer mit Kompression gearbeitet wird, dann müßten/würden Schreibzugriffe auf den internen NAND-Speicher mit nicht weiter komprimierbaren Daten (MPx, JPEG, viele Backup-Formate) deutlich langsamer laufen als solche mit komprimierbaren Daten.

Bei letzteren ergäbe sich dank der Kompression eine kleinere zu schreibende Datenmenge und damit vermutlich ein Zeitvorteil (vom gesparten Platz mal ganz abgesehen), aber bei bereits komprimierten Daten ist das am Ende nur eine Verschwendung von Rechenzeit. Da das ja beim UBIFS eigentlich ganz gut zu regeln ist, ob eine Datei komprimiert wird oder nicht, hätte ich jetzt irgendwo bei den NAS-Funktionen entsprechende Einstellungen erwartet (z.B. die Möglichkeit, für ein Verzeichnis die Kompression der innerhalb abgelegten Dateien generell ein- oder auszuschalten) ... bisher habe ich davon aber noch nichts gesehen.
 
Was ich noch nicht verstanden habe, sind die Pläne, die AVM mit der 2 MB-Partition unter "config" nun haben mag ...

Vielleicht möchte AVM die 2MB irgendwann einmal z.B. für individuelle AB-Ansagen verwenden (die derzeit im NAS-Speicher abgelegt werden) die so beim Sichern der Einstellungen mitgespeichert werden sollen/können. Ansagen/Dateien im NAS-Speicher werden (wenn ich mich jetzt nicht gerade täusche) imo nicht mit gesichert.




Mein Deutsch is nicht 100% perfekt,
Mein niederländisch wird dagegen vermutlich noch nicht einmal die 10%-Marke knacken... :mrgreen:

aber wann man die platinen von den 7581 sehe wollte:
Vielen Dank! Habe nun auch eine aktuelle Version der Tabelle hochgeladen welche dank dieser Informationen bzgl. der 7581 nun etwas an Informationen gewinnen konnte.

WIFI auch von Broadcom....
Leider kann man auf den Bildern die Bezeichnung der WiFi-Chips nicht erkennen, weißt du diesbezüglich zufälligerweise mehr? Ich würde z.B. auf BCM43460 oder BCM43602 tippen...
Und was steht eigentlich auf dem xDSL-AFE (falls du das wissen solltest)? Das ist der Chip rechts neben den 3 Elkos die relativ mittig auf dem PCB platziert sind.




@robert_s
Danke für den Hinweis bzgl. 6590, insb. für den Hinweis zur Artikel-Nr.
 
@qwertz.asdfgh:
Sicherlich hast Du auch den Beitrag zur 6590 irgendwo gesehen ... nach dem ersten Ausschnitt aus den Support-Daten hat die sogar 4 GB NAND-Flash eingebaut und weiterhin die 2 MB SPI-Flash - wobei das dem Environment nach die Sicht des ARM-Cores war. Wenn der "Begleittext" dort davon spricht, daß das GUI extrem schnell ist und es keine .254 mehr gibt, hat entweder AVM das GUI sehr viel schneller gemacht (der TO dort sollte eigentlich die 6490 kennen für den Vergleich und da macht dann auch 06.63 vs. 06.83 sicherlich nicht so viel aus - der ARM-Core ist nun mal etwas zäh) oder es ist tatsächlich auf den ATOM-Core umgezogen (das NAS-GUI dort war ja auch schon bei der 6490 deutlich flotter). Spaßigerweise(? - keine Ahnung, ob ich das wirklich spaßig finde) hat auch die 6590 wohl nach wie vor einen 2.6.39-Kernel.

Auf alle Fälle wird die 6590 vielleicht doch spannend ... wenn AVM diese "Umorganisation" tatsächlich auch für die 6490 machen sollte (von der Hardware spricht m.E. wenig dagegen - andere Puma6-Geräte betreiben das GUI ja auch dort), dann könnte ich mir zumindest die Verzögerung bei der 6490 erklären - wobei das ja auf der 6590 dann auch schon funktionieren würde und insofern ist diese Spekulation dann auch schon wieder weniger wahrscheinlich. Vielleicht ist doch nur die 6590 diese "New Architecture", wie sie seit der 06.80 (bzw. dem Labor davor) in der "/etc/puma6_helper.sh" zu finden ist, wenn die Environment-Variable "CONFIG_DOCSIS_MODEM" auf "y" gesetzt ist ... vielleicht rückt der TO im 6590-Thread ja noch ein paar mehr Informationen heraus. Ob er bis zu einer Shell kommt (oder ob er das überhaupt will), weiß ich nicht und bis zur Veröffentlichung der ersten Firmware-Images wird es wohl noch dauern - zumindest zur Zeit liefert auch die (hoffentlich korrekte) Abfrage des JUIS noch keinen Link auf die 06.83.
 
Sicherlich hast Du auch den Beitrag zur 6590 irgendwo gesehen ... nach dem ersten Ausschnitt aus den Support-Daten hat die sogar 4 GB NAND-Flash eingebaut und weiterhin die 2 MB SPI-Flash - wobei das dem Environment nach die Sicht des ARM-Cores war.
Wohl eher nicht:
##### BEGIN SECTION Support_Data Supportdata Linux fritz.box 2.6.39.3 #1 SMP PREEMPT Fri Mar 17 14:46:17 CET 2017 i686 GNU/Linux Version 148.06.83
Ein ARM-Core führt dann doch lieber ARM-Code als i686-Code aus...

hat entweder AVM das GUI sehr viel schneller gemacht (der TO dort sollte eigentlich die 6490 kennen für den Vergleich und da macht dann auch 06.63 vs. 06.83 sicherlich nicht so viel aus - der ARM-Core ist nun mal etwas zäh) oder es ist tatsächlich auf den ATOM-Core umgezogen (das NAS-GUI dort war ja auch schon bei der 6490 deutlich flotter).
Das wird es wohl sein. Die "alten" 6490er Firmwares hatten doch eine arg verbogene Architektur, auf den ARM-NP noch eine GUI draufzusetzen, der ja eigentlich das Kabelmodem, und insbesondere dessen sicherheitstechnische "Geheimnisse" kapseln sollte - mit den bekannten verheerenden Konsequenzen. Das hat Intel sich sicher auch nicht so gedacht, denn die GUI ist ja nun einmal eine "Anwendung" und sollte entsprechend auf dem dafür vorgesehenen Prozessor laufen. Das hat man mit der "neuen Architektur" wohl endlich glattgezogen.

Spaßigerweise(? - keine Ahnung, ob ich das wirklich spaßig finde) hat auch die 6590 wohl nach wie vor einen 2.6.39-Kernel.
Ich würde TI/Intel als "Ursache" nicht ausschließen. Wenn die nur ein Puma6-BSP mit dieser Kernel-Version liefern, und deren Änderungen/Treiber so tief in den Kernel eingreifen, dass eine Portierung auf einen aktuellen Kernel einfach "keinen Spaß" macht, dann lässt man es vielleicht besser einfach, bis Intel mal selber was neues liefert.

Denn umgekehrt wäre es ja wirklich schräg, wenn Intel etwas auf Basis eines 3er/4er-Kernels liefert, und AVM das dann auf den alten 2.6er-Kernel portiert...

Man müsste sich mal die Firmware eines Puma6-basierten Kabelmodems eines anderen Herstellers greifen und schauen, was da für ein Linux-Kernel drinsteckt.

- - - Aktualisiert - - -

Ah, schon gefunden:
https://sourceforge.net/projects/sb6190.arris/files/

linux-2.6.39.3-modified : The linux kernel.

Na, dann würde ich doch sagen, dass das so von Intel kommt.
 
@robert_s:
Bitte richtig lesen ... ich schrieb ja eindeutig (und nicht ohne Absicht): "dem Environment nach" und dort steht in dem anderen Thread der Eintrag "Fritz_Box_HW220a".

Wagt man dann einen Blick in die "/etc/puma6_helper.sh" aus einer neueren Firmware (selbstverständlich aus einer, die nicht aus der 6590 stammt, auch das geht aus dem Rest meines Textes ja deutlich hervor), ist das nun einmal die Sicht des ARM-Cores:
Code:
[COLOR="#FF0000"]is_puma_arm()[/COLOR]
{
  if [ "$CONFIG_PRODUKT" = Fritz_Box_HW199a ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW204a ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW213a ] || [COLOR="#FF0000"][ "$CONFIG_PRODUKT" = Fritz_Box_HW220a ][/COLOR] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW231a ] ; then
    return 0
  else
    return 1
  fi
}

[COLOR="#008000"]is_puma_atom()[/COLOR]
{
  if [ "$CONFIG_PRODUKT" = Fritz_Box_HW199x ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW204x ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW213x ] || [COLOR="#008000"][ "$CONFIG_PRODUKT" = Fritz_Box_HW220x ][/COLOR] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW231x ] ; then
    return 0
  else
    return 1
  fi
}

is_puma_na()
{
  if [ "$CONFIG_DOCSIS_MODEM" = y ] ; then
   # New Architecture
   return 0
  else
   # Old Architecture
   return 1
  fi
}

is_puma6_arm()
{
  if is_puma_arm && ! is_puma_na ; then
   # PUMA6 ARM
   return 0
  else
   # no PUMA6 ARM
   return 1
  fi
}

is_puma_na_arm()
{
  if is_puma_arm && is_puma_na ; then
    return 0
  else
    return 1
  fi
}

is_puma6_atom()
{
  if is_puma_atom && ! is_puma_na ; then
   # PUMA6 ATOM
   return 0
  else
   # no PUMA6 ATOM
   return 1
  fi
}

is_puma_na_atom()
{
  if is_puma_atom && is_puma_na ; then
    return 0
  else
    return 1
  fi
}

is_puma6()
{
  if is_puma_arm || is_puma_atom ; then
   # PUMA6
   return 0
  else
   # no PUMA6
    return 1
  fi
}
... zumindest nach dem bisherigen Stand der Firmware.

Wenn dann irgendwann mal klar ist, welchen Wert die ebenfalls zuvor angesprochene Variable "CONFIG_DOCSIS_MODEM" wirklich hat, dann kann man auch den Rest der Unterscheidungen in der gezeigten Shell-Datei nachvollziehen und damit die Frage nach der "New Architecture" beantworten.

Wobei ich das "i686" tatsächlich nicht gesehen habe und damit auch klar sein dürfte, daß der von mir zuvor nur vermutete Transfer wohl wirklich stattgefunden hat.

Ansonsten kann man bei einer Bemerkung "weil die Architektur A wohl eher keine Befehle aus Architektur B ausführt" auch mal auf der Nase landen - auch wenn hier eine Emulation (x86 auf ARM) eher unwahrscheinlich ist, ist das für die "Gegenrichtung" alles andere als "seltsam"; vielleicht noch auf so einem Consumer-Router, aber vermutlich auch nicht mehr lange.

- - - Aktualisiert - - -

Ansonsten habe ich leider keinen Zugriff auf das Intel CEFDK für den Puma6 ... ich kenne das aber zumindest von anderen Stellen so, daß der Chip-Hersteller seinerseits Kernel-Patches für verschiedene Versionen bereitstellt und der Hardware-Hersteller damit dann "seinen" Kernel patcht.

Wenn Intel das wirklich nur für 2.6.39 gemacht haben sollte (das ist ja die letzte 2.6er-Version überhaupt und die hat zumindest einige wichtige Änderungen an Bord, z.B. die komplette Abschaffung des "Big Kernel Lock") und tatsächlich anstelle von Patches (die man dann auf einen 3er-Kernel anpassen könnte, schließlich ist der erste 3er eigentlich nur die Umstellung der Nummerierung und er hätte auch 2.6.40 heißen können - in den neun Monaten von 2.6.39 zur 3.2 (das ist ein LTS-Zweig) wurde ja nicht alles komplett umgeschrieben) ein komplettes Source-Paket bereitstellt, was nun kein Hersteller erst per Differenzbildung in einen neueren 3er-Kernel integrieren will, dann könnte ich dieser Annahme folgen. Ansonsten hätte auch Arris/Motorola halt den Weg des 2.6.39-Kernel gewählt und seinerseits das veröffentlicht, was in dem konkreten Gerät eingesetzt wird ... und nicht direkt die (Patch-)Dateien aus einem Intel Development Kit.

Ich wäre aber schon deshalb verblüfft, wenn es von Intel (ausschließlich) einen kompletten Kernel-Tree geben sollte, weil dann Intel auch automatisch dafür zuständig wäre, bei einem (Security-)Problem an anderer Stelle im 2.6.39-Kernel neue Quellen bereitzustellen, damit die Hersteller ihrerseits das Problem angehen können. Das ist - nach dem was ich jedenfalls ansonsten kenne - ein eher ungewöhnliches Vorgehen ... auch wenn es natürlich das "Delegieren" der Verantwortung von Herstellern an den Chipsatz-Hersteller wesentlich erleichtern kann.

2.6.39 ist halt lange raus aus der "Maintenance" (da gibt es auch keinen "offiziellen" Maintainer, der noch die 2.6er wartet - es gab eben keine wirklich tiefgreifenden Veränderungen beim "Sprung" auf die neue Nummerierung) und selbst der bei den VR9-Modelle verwendete 3.10 als LTS-Version endet eigentlich irgendwann in diesem Jahr (noch vor dem 3.2-Zweig). Gerade bei den x86-Prozessoren dürfte es aber auch einiges an Verbesserungen in neuen Kernel-Versionen geben, die sich richtig positiv bemerkbar machen - das ist (oder war es zumindest mal) nun mal die primär unterstützte Plattform (gerade auch für Server und viele Performance-Verbesserungen zielten auf Serverbetrieb ab) - allerdings mögen sich beim Netzwerk-Stack tatsächlich Anpassungen für Offloading und Verbesserungen im Vanilla-Kernel ab und an mal ins Gehege kommen.
 
Wobei ich das "i686" tatsächlich nicht gesehen habe
Ebenso wie die Zeile:
##### TITLE Produkt Fritz_Box_HW220x

Ansonsten kann man bei einer Bemerkung "weil die Architektur A wohl eher keine Befehle aus Architektur B ausführt" auch mal auf der Nase landen - auch wenn hier eine Emulation (x86 auf ARM) eher unwahrscheinlich ist,
Und deshalb so, wie sie gemacht wurde, auch völlig zutreffend ist.

Ansonsten habe ich leider keinen Zugriff auf das Intel CEFDK für den Puma6 ...
Hast Du mal auf den Link geklickt, den ich oben gepostet habe? Da scheinen mir doch ein paar recht interessante Pakete dabei zu sein, welche direkt aus dem CEFDK stammen dürften...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.