Angepinnt Telnet / Bootstrap ab FW-Version 3 - Hardware-Serial-COM

      @danXde danke für die schnelle Antwort... geht um Seite 5 in diesem Thread =>

      "Die Ausgabe des Logs lässt vermuten, daß im Startscript ( /etc/profile ) irgendein kleiner Fehler sitzt... er denkt, da wäre ein '&' zuviel, welches aber wohl eher einfach an der falschen Stelle sitzt.... "

      genau diese Prob habe ich aktuell auch. Für eine kleine Hilfe wäre ich dankbar.

      LG!
      @shMike ok, ein wenig klarer. Aber verstanden habe ich es immer noch nicht, wo es klemmt und warum das bei Dir passiert ist. Falls der Router nicht mehr normal startet, müsstest Du den notfallmodus nutzen. Dazu den Rechner mit einer Festen IP im 192.168.2.0/24 (ausser 1) konfigurieren. Dann mit Netzwerkkabel den SPH verbinden. Dann den SPH einschalten. Sofort, wenn ein Link signalisiert wird, per Browser auf die 192.168.2.1 verbinden. ...dann solltest Du eine Image-Datei hochladen können, welche dann installiert wird. ....danach müsstest Du allerdings neu den Break machen.

      Grüße

      danXde
      Wie muss ich nochmal die /etc/profile anpassen, damit Telnet bzw. SSH auch ohne aktive DSL-Verbindung aktiviert werden?
      Normalerweise wartet er ja auf DSL Sync, bevor es weiter geht. Liegt das an "startbsp"??
      UpdatE:
      OK, ich habs, in /opt/bootstrap_init.sh die Dropbear-Zeilen vor

      Quellcode

      1. #wait for dsl
      2. while [ $(date | cut -d ' ' -f 7) = 1970 ]; do sleep 1 ; done"
      schieben.

      Gibt es einen Grund dafür, dass Dropbear erst nach Aufbau des DSL Sync aktiviert wird? @danXde


      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „GeeGee“ ()

      Ich habe das Update von FW ...005 auf ...007 durchgeführt und war kurz davor, meine Anpassung in /etc/profile nicht zu verlieren, d.h. ich habe fast Root/Konsolenzugriff behalten ohne die Kiste erneut aufschrauben zu müssen.
      Es nervt mich unglaublich, nach jedem Firmwareupgrade wieder den Flash-Chip kurzschließen zu müssen und so weiter...

      Vorbereitung:
      1. per SSH oder Telnet auf Konsole anmelden
      2. profile-Datei nach /tmp sichern:
      - cd /tmp
      - cp /etc/profile .
      3. konfigdir mounten mit Lese-&Schreibeberechtigung
      - mkdir rmnt
      - mount -t jffs2 /dev/mtdblock0 /tmp/rmnt
      - mount -o remount,rw /dev/mtdblock0 /tmp/rmnt

      Vorgehen:
      1. Neue Firmware auf PC downloaden
      2. Manuelles Firmwareupdate per Web starten
      3. Mittels "ps" die PID der UPG-Prozesses identifizieren, z.B. 5546
      4. UPG-Prozess killen mit "kill -9 5546", wobei 5546 durch die PID zu ersetzen ist.
      5. Upgrade manuell auf Konsole starten mittels "upg -f /var/image.bin -y 1 -c web". Im Gegensatz zum normalen Weg, wird so nicht gleich nach dem Upgrade rebootet.
      6. Man kann den Meldungen entnehmen was alles aktualisiert wurde, bei 005 zu 007 wird nur LTE von H1331.11.994.13.113d auf ...113e gehoben, sonst nichts.
      7. Angepasste profile-datei zurückspielen: cp /tmp/profile /tmp/rmnt/etc/profile -y
      8. Reboot

      Es scheitert daran, dass der Router nach dem Firmwareupgrade offensichtlich eine andere Konfiguration startet, weil zwischen primary und secondary getauscht wird.
      Auf der seriellen Konsole zeigt er dann "Boot from slave system!" oder eben "Boot from main system!".
      Ich wüßte gerne, wo das jeweils andere filesystem auf dem MTD versteckt ist, habe es aber leider noch nicht gefunden. Habt ihr Ideen?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „GeeGee“ ()

      Es scheint, als ob der Bootloader je nachdem, ob gerade das MASTER oder das SLAVE gebootet wird, an unterschiedlichen Stellen auf dem Flash-Chip nach seinen Images sucht:
      1. Main-System
      Boot from main system!
      SIGN CHK ALWAYLYS.
      get bootflag = 1
      check tag at block 1 crc ok
      Check Image Crc Success
      I have find uImage at block 11
      I have get uImage size at block 56
      Load SD5115 uImage SIZE: 5818492


      2. Slave System
      oot from slave system!
      SIGN CHK ALWAYLYS.
      get bootflag = 2
      check tag at block 6 crc ok
      Check Image Crc Success
      I have find uImage at block 651
      I have get uImage size at block 696
      Load SD5115 uImage SIZE: 5818492

      Es stellt sich nun die Frage, wie man diese entsprechenden Stellen auf dem Flash finden und mounten kann, um darin die Anpassung der /etc/profile-Datei vorzunehmen, so dass unser "jailbreak" bzw. root künftige Firmwareupgrades übersteht?
      @danXde: wenn ich mich recht erinnere, war der Grund wirklich einfach nur die Zeiteinstellung... Telnet sollte auch ohne korrekte Zeit funktionieren, andere Dienste teils nicht. (der SPH hat keine RTC - er bekommt nur bei aktiver Verbindung per NTP eine Zeitbasisi)

      Manches, was mit Verschlüsselung zu tun hat braucht zB. eine (halbwegs) korrekte Zeit - sonst geht nix.

      @GeeGee: der SPH hat zwei Firmware-'Slots', welche er beim Flashen abwechselnd nutzt... bei Fehlern schaltet er einfach zurück auf den anderen. Das kann ein Fehler beim Flashen sein, oder aber auch ein Fehler beim Boot zu einem späteren Zeitpunkt - Letzteres kann einen dann echt verwirren, wenn man zB. unterschiedliche Modifikationen hatte... :D
      (ist mir passiert - brauchte 'nen Moment bis mir auffiel, daß die Zeitstempel meiner Scripts einen 'Rücksprung gemacht hatten...')

      mfg, emkay

      >6. Man kann den Meldungen entnehmen was alles aktualisiert wurde, bei 005 zu 007 wird nur LTE von H1331.11.994.13.113d auf ...113e gehoben, sonst nichts.

      Wenn nur diese datei geändert ist, köntest du es hier posten ? Vieleicht verstehe Ich was nicht, aber dann muss ich nur diese datei manuel ersetzen oder ?

      Anyway:

      bash-4.3# cat /proc/mtd
      dev: size erasesize name
      mtd0: 05000000 00020000 "rootfs"
      mtd1: 10000000 00020000 "all"
      mtd2: 00aa0000 00020000 "config"
      mtd3: 000a0000 00020000 "equip"
      mtd4: 000a0000 00020000 "upgflag"
      mtd5: 00020000 00020000 "blrom"
      mtd6: 000a0000 00020000 "rootfstag"
      mtd7: 00940000 00020000 "reserved"
      mtd8: 05ea0000 00020000 "html"
      mtd9: 001a0000 00020000 "wlanrf"
      mtd10: 0fea0000 00020000 "kernel"
      mtd11: 0aea0000 00020000 "kernelbak"
      mtd12: 00280000 00020000 "configbak"
      mtd13: 04600000 00020000 "module"
      bash-4.3# df
      rootfs 81920 36340 45580 44% /
      mtd:rootfs 81920 36340 45580 44% /
      /dev/mtdblock2 10880 864 10016 8% /config
      /dev/mtdblock12 2560 424 2136 17% /configback
      /dev/mtdblock13 71680 25144 46536 35% /var/lte_fota
      /dev/sda1 1896608 504728 1295536 28% /mnt/_________USB_DISK_2.0-13FE2D1E_usb1_1
      /dev/sda1 1896608 504728 1295536 28% /tmp/bsmnt
      /dev/sda1 1896608 504728 1295536 28% /opt
      /dev/sda1 1896608 504728 1295536 28% /bin

      bash-4.3# ls /var/lte_fota/
      lte_need_update.ini # Contains 0
      lte_version.ini # Contains H1331.11.994.13.112

      lte_fota.bin

      base=0xb8000000 sector=0 board_id=Hybrid system_type=1 multi_upg_start_type=1 hgw_softversion=HYBRIDV100R001C03B027 hgw_softversion_web=050124.04.00.005 .....




      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Salamander“ ()

      Hallo Salamander,
      leider ist das nicht mal einfach so eine Datei die getauscht werden muss, sondern das Script "upg" entnimmt der neuen Firmware (.BIN-Datei) bestimmte Partitionen und schreibt sie aufs Flash. Da ich in die Binärdatei /bin/upg nicht hineinschauen kann, kann ich den Teil nicht extrahieren.
      Bis wir eine Lösung für das Überleben von /etc/profile eines Flashvorgangs gefunden haben, heißt es leider weiterhin bei jedem Update/Flashvorgang den Lötkolben auspacken.

      ALLE: unter github.com/logon84/Hacking_Huawei_HG8012H_ONT hat jemand beschrieben, wie er ein Huaweigerät "gehackt" hat. Vielleicht können wir Ansätze davon für unser Gerät übernehmen? Etwa das binary von "mtd" aus Openwrt wäre hilfreich im Umgang mit dem Flash und irgendwie müssen wir ja die Einstellung verändern können, ob nun das MASTER oder das SLAVE-System gebootet wird, irgend ein Parameter, der dem Bootloader übergeben wird.

      eMKay77 schrieb:



      @GeeGee: der SPH hat zwei Firmware-'Slots', welche er beim Flashen abwechselnd nutzt... bei Fehlern schaltet er einfach zurück auf den anderen. Das kann ein Fehler beim Flashen sein, oder aber auch ein Fehler beim Boot zu einem späteren Zeitpunkt -
      mfg, emkay

      Genau, das master und das slave-system, wobei beide auf dem gleichen Flash-Chip liegen und der Bootloader durch irgend eine Anweisung entscheidet, ab welchem Speicherbereich er eben welche Partition lädt.
      Konntest Du herausfinden, wie man solch einen "Fehler" herbeiführt? Etwa Reset-Knop während des Stromeinschaltens hereinstecken oder ähnliches?
      Ist es so, dass beim Flashen der jeweils andere Flash-Slot beschrieben wird, so dass bei einem korrupten Update zurück auf die alte Version geschaltet werden kann?

      Wahrscheinlich ist der für uns relevante Block /dev/mtdblock0 also einmal auf den primären und einmal auf den sekundären gemappt.
      Ziel müsst es sein, Updates per upg einzuspielen, damit am Ende nicht automatisch neugestartet wird.
      Dann müsste man den künftitgen und derzeit nicht aktiven /dev/mtdblock0 mounten und dort die Profile-Datei manipulieren, was alles über die bestehende SSH-Session und ohne Lötkolben/serielle Konsole ginge.
      DAS WÄRE MAL WAS.