DreamOS - DM900: Manchmal kein Netzwerk nach einem reboot

  • Es kommt in unregelmäßigen Abständen und nicht reproduzierbar vor, dass meine dm900 nach einem reboot keine Verbindung zum Netzwerk hat.



    config:
    statische IP, dm900 IP nicht in der DHCP Range


    Im journal findet man dann das

    Code
    1. root@dm900uhd:~# journalctl -x|grep connman
    2. Jan 01 01:00:01 dm900uhd systemd[1]: connman-wait-online.service: Job connman-wait-online.service/start failed with result 'dependency'.
    3. Jan 01 01:00:05 dm900uhd enigma2[267]: connman not AVAILABLE
    4. Jan 01 01:00:20 dm900uhd enigma2[267]: ClockModel: unable to connect to connman


    Nach einem reboot oder de- und reaktieren des Adapters ist die Box wieder im Netzwerk, manchmal muss ich aber auch das dropbear.service über telnet neu starten damit die Box über ssh erreichbar ist


    Weil ich manchmal (über das Netzwerk) aus dem standby aufnehme, habe ich mir einen watchdog gebaut, der beim Boot prüft, ob die Box im Netzwerk ist und gegebenfalls das netzwerk so lange neu startet, bis die Box im Netz ist, aber das ist auch nur ein workaround


    tritt das bei anderen dm900 bzw. DreamOS Boxen auch sporadisch auf oder ist das ein lokales Problem?

  • Ich hatte es schon ein paar mal am Anfang mit der 920er, in letzter zeit aber nicht mehr. Das liegt wohl daran dass ich aus Angst das meine Aufnahmen kaputt gehen - Box bleibt beim booten hängen - nicht mehr im Idle gehe und auch so gut wie nicht mehr die Box neu starte. :)

  • @juanito_perez
    ja, das habe ich schon durch


    die Box hängt an einem 8-Port Gigabit LAN Switch an dem auch eine DM800SE hängt - da hatte ich das in 5 Jahren nicht einmal
    Ich hab' auch schon das Kabel bzw. den Port zur dm900 mit dem dem der DM800SE getauscht, tritt trotzdem auf


    und wie gesagt Box bzw. Netzwerk neu starten und alles ist gut und tritt dann auch bei x Neustarts der Box nicht mehr auf, dann wieder gehäuft


    ich glaub, dass es an systemd bzw an den Abhängigkeiten liegt, journalctl sagt ja, dass der Job connman-wait-online.service nicht gestartet werden konnte.


    Aber vielleicht sollte ich mal neu flashen ...

  • das war wohl noch OE2.2


    ich hab' mir den Threat mal durchgelesen
    Aber über lange Bootzeiten kann ich nicht klagen, auch wenn die Box keine Netzwerkverbindung beim Start erhält


    Ich hab mir in Menü - System - Netzwerk auch einen "Network Restart" wie im OE2.0 eingebaut, mit dem ich connman und dropbear neu starte
    Nach dem Neustart des Netzwerks ist Ruhe, also dann keine Netzwerkprobleme im laufenden Betrieb


    Sieht wohl nach einer längeren Testphase aus ...


    Also erstmal neu flashen, vielleicht habe ich auch nur zu viel im systemd rumgepfuscht ... :D

  • tritt das bei anderen dm900 bzw. DreamOS Boxen auch sporadisch auf

    Hatte ich mit meiner DM900 glücklicherweise noch nie.
    Wäre bei mir aber auch Fatal, da ich keine HDD eingebaut habe und alle Aufnahmen auf das NAS gehen.
    IP ist auch an der DM900 fix ausserhalb des DHCP Range des Routers. Dazwischen ist noch ein TL-SG2008 8-Port Switch.

  • Ich hab das neuerdings auch (DM920) :/ aber erst nach dem grossen Update, aber auch nicht exakt danach .... Weiss nicht was ich grossartig verändert habe


    Bei mir ist es aber so, dass wenn man nichts macht (also Verbindung de/aktivieren) kommt dann doch irgendwann das Netzwerk von alleine wieder, braucht aber ca. 2 Min.


    Aufgefallen war es bei mir durch das FritZCall Plugn, weil das beim Systemstart Verbindungsmeldungen anzeigt ... no route to host etc....


    Habe nun erstmal beim Fritzcall Plugin die Meldungen deaktiviert.


    Naja vlt auch noch n n anderes Problem bei mir.


    Gruß

  • seit dem ich den Threat erstellt habe, prüfe ich per cronjob beim Boot ob eine Netzwerkverbindung besteht und versuche das Netzwerk gegebenenfalls automatisch zu reparieren, falls der ping zum Router fehl schlägt. Aber kaum "logge" ich mit, tritt es nicht mehr auf :D


  • bei IP= IP des Routers, Google DNS oder what ever immer online ist eintragen


    /usr/script/networkwd.sh

    wenn du keine netzwerkverbindung hast, sollte das script das journal gefiltert nach eth0 und conmann nach /media/sd/network_journal.log dumpen. Den Pfad kann man natürlich anpassen. /tmp ist nicht so gut ...


    und ich hab' mich geirrt, ich rufe es nicht per cronjob beim boot auf, sondern über die /etc/rc.local



    /etc/rc.local (Pfad für networkwd.log anpassen, am Besten auf einen nicht flüchtigen Speicher)

    Bin aber nicht sicher ob das script zu 100% funktioniert, ich hatte wie gesagt noch kein "network failed", seit dem ich den watchdog beim Boot laufen lasse

  • jetzt hat es mich wieder erwischt, nach reboot keine Verbindung über telnet, ssh, ftp, http


    seriell mit der Box verbunden: restart connman.service alleine bringt nichts
    eth0 wird erkannt und bekommt die IP zugewiesen
    interessanterweise kann ich von der Box eine FQDN Adresse im Netz anpingen, Netzwerk und DNS funktioniert scheinbar


    connman.service: active / loaded
    dropbear.service: active / loaded



    nach
    systemctl restart sockets.target


    ist die Box wieder über telnet, ssh, ftp, http ereichbar



    \\Edit
    scheinbar werden die sockets nicht gestartet




  • Hi,


    bleibst du da dran? Eine Lösung wäre genial da bei meiner 7080hd auch ab und zu mal das Netzwerk nach einem Start nicht erreichbar ist. Vor ein paar Tagen mußte ich die Box sogar 3x Neustarten bevor das Netzwerk da war bzw. Darauf zugegriffen werden konnte.
    Man erkennt es auch immer gut daran das die LEDˋs der. Etzwerkbuchse aus bleiben.

  • ich hab das /usr/script/networkwd.sh im obigen post angepasst


    das schreibt das ganze journal nach /media/sd oder wohin man es haben will (JOURNALDUMP= anpassen) und startet dann das socket.target und dann das connman.service neu


    Wenn das funktoniert ist das aber nur ein workaround - kein bugfix


    Zumindest hat man auch nach einem Reboot in /media/sd/network_journal.log das letzte journal und in /media/sd/networkwd.log dokumentiert wie oft das auftritt.



    Vielleicht sollte ich auch noch einbauen, dass z.B. nach dem 5. Versuch das socket.target und conmann.service neu zustarten die Box komplett neu startet, damit das nicht endlos läuft ...