.titleBar { margin-bottom: 5px!important; }

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

Dieses Thema im Forum "FRITZ!Box tot? Recover, Firmware Up-/ Downgrade" wurde erstellt von qwertz.asdfgh, 2 Juli 2015.

Schlagworte:
  1. Daniel Lücking

    Daniel Lücking IPPF-Promi

    Registriert seit:
    18 Apr. 2008
    Beiträge:
    3,559
    Zustimmungen:
    124
    Punkte für Erfolge:
    63
    Beruf:
    Onlinejournalist (Stud. Master Kulturjournalismus)
    Ort:
    Berlin
    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).
     
  2. MoDis

    MoDis Neuer User

    Registriert seit:
    15 Apr. 2007
    Beiträge:
    11
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #62 MoDis, 3 Dez. 2016
    Zuletzt bearbeitet: 3 Dez. 2016
    @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.
     
  3. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  4. MoDis

    MoDis Neuer User

    Registriert seit:
    15 Apr. 2007
    Beiträge:
    11
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  5. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
  6. GokuSS4

    GokuSS4 Mitglied

    Registriert seit:
    15 Apr. 2008
    Beiträge:
    661
    Zustimmungen:
    10
    Punkte für Erfolge:
    18
    Ort:
    Achim
    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?
     
  7. MoDis

    MoDis Neuer User

    Registriert seit:
    15 Apr. 2007
    Beiträge:
    11
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #67 MoDis, 4 Dez. 2016
    Zuletzt bearbeitet: 5 Dez. 2016
    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.
     
  8. MoDis

    MoDis Neuer User

    Registriert seit:
    15 Apr. 2007
    Beiträge:
    11
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  9. iol

    iol Neuer User

    Registriert seit:
    6 März 2017
    Beiträge:
    3
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #69 iol, 7 März 2017
    Zuletzt bearbeitet: 7 März 2017
    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
     
  10. qwertz.asdfgh

    qwertz.asdfgh IPPF-Promi

    Registriert seit:
    18 Feb. 2011
    Beiträge:
    4,462
    Zustimmungen:
    60
    Punkte für Erfolge:
    48
    #70 qwertz.asdfgh, 5 Apr. 2017
    Zuletzt bearbeitet: 5 Apr. 2017
    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.


    [hr]
    [/hr]

    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: [email protected] {
    		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: [email protected] {
    		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: [email protected] {
    		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: [email protected] {
    		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)


    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)
     
  11. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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]
    
     
  12. qwertz.asdfgh

    qwertz.asdfgh IPPF-Promi

    Registriert seit:
    18 Feb. 2011
    Beiträge:
    4,462
    Zustimmungen:
    60
    Punkte für Erfolge:
    48
    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...
     
  13. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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:
    [email protected]:~ $ [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:
    [email protected]:~ $ [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.
     
  14. loekf

    loekf Neuer User

    Registriert seit:
    21 März 2017
    Beiträge:
    2
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
  15. robert_s

    robert_s Mitglied

    Registriert seit:
    1 Juni 2006
    Beiträge:
    479
    Zustimmungen:
    10
    Punkte für Erfolge:
    18
  16. qwertz.asdfgh

    qwertz.asdfgh IPPF-Promi

    Registriert seit:
    18 Feb. 2011
    Beiträge:
    4,462
    Zustimmungen:
    60
    Punkte für Erfolge:
    48
    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.

    [hr]
    [/hr]

    Mein niederländisch wird dagegen vermutlich noch nicht einmal die 10%-Marke knacken... :mrgreen:

    Vielen Dank! Habe nun auch eine aktuelle Version der Tabelle hochgeladen welche dank dieser Informationen bzgl. der 7581 nun etwas an Informationen gewinnen konnte.

    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.

    [hr]
    [/hr]

    @robert_s
    Danke für den Hinweis bzgl. 6590, insb. für den Hinweis zur Artikel-Nr.
     
  17. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @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.
     
  18. robert_s

    robert_s Mitglied

    Registriert seit:
    1 Juni 2006
    Beiträge:
    479
    Zustimmungen:
    10
    Punkte für Erfolge:
    18
    Wohl eher nicht:
    Ein ARM-Core führt dann doch lieber ARM-Code als i686-Code aus...

    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.

    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/

    Na, dann würde ich doch sagen, dass das so von Intel kommt.
     
  19. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,793
    Zustimmungen:
    666
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @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.
     
  20. robert_s

    robert_s Mitglied

    Registriert seit:
    1 Juni 2006
    Beiträge:
    479
    Zustimmungen:
    10
    Punkte für Erfolge:
    18
    Ebenso wie die Zeile:
    Und deshalb so, wie sie gemacht wurde, auch völlig zutreffend ist.

    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...