Hi,
das ist schon richtig so, mein Router hat die 192.168.1.1 und in deinem originalem Script steht dort die 8.8.8.8
Hi,
das ist schon richtig so, mein Router hat die 192.168.1.1 und in deinem originalem Script steht dort die 8.8.8.8
nein, in meinem script steht 192.168.1.1
und wenn die Box bei jedem reboot das Netzwerk neu startet stimmt etwas nicht mit deinem Anpassungen in dem script bzw. in der rc.local,
hier funktioniert das Script einwandfrei
war wieder einmal soweit
Nach einem rebot keine Verbindung über ssh, telnet und ftp möglich, das Netzwerk wurde aber aufgebaut, d.h. die daemons laufen nicht
Zugriff auf das Web-IF über http und https ok.
seriell verbunden, eth0 wurde erkannt, IP (statisch) wurde zugewiesen, ping dreambox.de und auf den gateway ok, deshalb ist der watchdog nicht angesprungen
status dropbear.socket, vsftpd.socket und busybox-telnetd.socket sind tot, nach einem restart der sockets wieder alles ok
Ich habe mittlerweile 2 verschiedene Ursachen gefunden
1. eth0 wird nicht erkannt, dann geht gar nichts, dann hilft ein connmann neustart oder ein sockets.target neustart
2. eth0 wird erkannt, Netzerkverbindung ist ok, aber dropbear.socket, vsftpd.socket und busybox-telnetd.socket sterben beim bootup - d.h. keine Verbindung über diese Protokolle möglich, dann reicht es, die betroffenen sockets neu zu starten
tritt ca. bei jedem 10. bootup auf
Vielleicht kann ein Dev ja mal sagen, wonach ich im journal suchen kann, um den Fehler eingrenzen zu können, die Box ist ja permanent seriell mit einem Rasbperry pi verbunden
root@dm900uhd:~# ps
PID TTY TIME CMD
319 ttyS0 00:00:00 bash
6861 ttyS0 00:00:00 ps
root@dm900uhd:~# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
link/ether 00:09:34:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.178.90/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
root@dm900uhd:~# ping -c 1 dreambox.de
PING dreambox.de (82.149.226.170): 56 data bytes
64 bytes from 82.149.226.170: seq=0 ttl=53 time=28.101 ms
--- dreambox.de ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 28.101/28.101/28.101 ms
root@dm900uhd:~# systemctl status dropbear.service vsftpd.service busybox-telnetd.service
â�● dropbear.service - LSB: Dropbear Secure Shell server
Loaded: loaded (/etc/init.d/dropbear; generated; vendor preset: enabled)
Active: active (exited) since So 2018-09-30 20:33:23 CEST; 18min ago
Docs: man:systemd-sysv-generator(8)
Process: 255 ExecStart=/etc/init.d/dropbear start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/dropbear.service
Sep 30 20:33:23 dm900uhd systemd[1]: Starting LSB: Dropbear Secure Shell server...
Sep 30 20:33:23 dm900uhd dropbear[255]: Starting Dropbear SSH server: dropbear.
Sep 30 20:33:23 dm900uhd systemd[1]: Started LSB: Dropbear Secure Shell server.
Failed to dump process list, ignoring: Unit vsftpd.service is masked.
Failed to dump process list, ignoring: Unit busybox-telnetd.service is masked.
â�● vsftpd.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
â�● busybox-telneded: masked (/dev/null; bad)
Active: inactive (dead)
root@dm900uhd:~# systemctl status dropbear.socket vsftpd.socket busybox-telnetd.socket
â�● dropbear.socket
Loaded: loaded (/lib/systemd/system/dropbear.socket; enabled; vendor preset: enabled)
Active: inactive (dead)
Listen: [::]:22 (Stream)
Accepted: 0; Connected: 0
â�● vsftpd.socket
Loaded: loaded (/lib/systemd/system/vsftpd.socket; enabled; vendor preset: enabled)
Active: active (listening) since So 2018-09-30 20:33:23 CEST; 19min ago
Listen: [::]:21 (Stream)
Accepted: 1; Connected: 0
Sep 30 20:33:23 dm900uhd systemd[1]: Listening on vsftpd.socket.
â�● busybox-telnetd.socket
Loaded: loaded (/lib/systemd/system/busybox-telnetd.socket; enabled; vendor preset: enabled)
Active: inactive (dead)
Listen: [::]:23 (Stream)
Accepted: 0; Connected: 0
root@dm900uhd:~# systemctl restart dropbear.socket vsftpd.socket busybox-telnetd.socket
root@dm900uhd:~# systemctl status dropbear.socket vsftpd.socket busybox-telnetd.socket
â�● dropbear.socket
Loaded: loaded (/lib/systemd/system/dropbear.socket; enabled; vendor preset: enabled)
Active: active (listening) since So 2018-09-30 20:54:39 CEST; 12s ago
Listen: [::]:22 (Stream)
Accepted: 0; Connected: 0
Sep 30 20:54:39 dm900uhd systemd[1]: Listening on dropbear.socket.
â�● vsftpd.socket
Loaded: loaded (/lib/systemd/system/vsftpd.socket; enabled; vendor preset: enabled)
Active: active (listening) since So 2018-09-30 20:54:39 CEST; 12s ago
Listen: [::]:21 (Stream)
Accepted: 1; Connected: 0
Sep 30 20:54:39 dm900uhd systemd[1]: Listening on vsftpd.socket.
â�● busybox-telnetd.socket
Loaded: loaded (/lib/systemd/system/busybox-telnetd.socket; enabled; vendor preset: enabled)
Active: active (l since So 2018-09-30 20:54:39 CEST; 12s ago
Listen: [::]:d systemd[1]: Listening on busybox-telnetd.socket.
root@dm900uhd:~#
Alles anzeigen
Hi,
könntest du dann bitte mal deine beiden Dateien als Anhang posten. Dann könnte ich wenigsten Fehler durch falsche Formatierung ausschließen.
war wieder einmal soweit
Vielleicht kann ein Dev ja mal sagen, wonach ich im journal suchen kann, um den Fehler eingrenzen zu können, die Box ist ja permanent seriell mit einem Rasbperry pi verbunden
Update 2.10.2018 eingecheckt aber leider noch immer das gleiche. Auch von mir die bitte an Devs um hilfe
Hi,
zum Netzwerk nochmal zum Verständnis. Es kann doch nicht an dem Kabel oder dem Switch liegen wenn der Netzwerktreiber erst garnicht geladen wird nach dem booten oder wie bei mir auch schon das nach ca. 1 Minute das Netzwerk dann plötzlich doch da war aber meistens bleibt es bis zum nächsten Neustart „tot“.
Ich übernimm das mal aus dem anderen Tread. Ich lese diesen hier ja schon länger mit.
Ich habe echt keine Ahnung ob das an den Netzwerk-Komponenten liegt oder an der Hardware der Dreambox.
Es könnte ja sein das einige Bauteile in der Dreambox die das Netzwerk betreffen etwas ausserhalb der Toleranz liegen und das Problem verursachen.
Oder hat wer das Problem an 2 Dreamboxen zugleich ? Dann könnte es eher an Netzwerkkomponenten im Heimnetz liegen.
Ihr habt bestimmt schon mal z.b. einen Switch dazwischen gehängt um zu prüfen ob das Problem dann immer noch besteht.
Oder anders, geht das Netzwerk im RescueLoader immer ?
Ihr habt ja mal angesprochen das es im Jungfräulichen Image ging, und paar Plugins später nicht mehr ? Ist das noch aktuell so ?
Ich bin sehr froh, das ich noch nie irgend welche Netzwerk Probleme hatte. Denn so was wäre für mich ein komplettes NoGo, weil ich ausschliesslich das NAS als Datenträger habe.
Hi,
auf der 920er hatte ich das auch schon aber erst ein oder zweimal. Auf der 7080er kommt es öfter vor nur reproduzieren läßt sich das leider nicht. Mit der 7020hd hatte ich nie Probleme in dieser Hinsicht und die 7020er hing an den Anschlüßen wo jetzt die 7080er und die 920er angeschlossen sind.
Das das Netzwerk nicht gefunden wird bzw. im Netzwerkmenü der Boxen war kein Netzwerk zu sehen und die LED an der Netzwerkbuchse blieben aus bis zum nächsten Neustart hatte ich auch mit Jungfräulichen Images.
Im Rescue Loader hatte ich noch keine Probleme.
Am Netzwerk liegt es nicht, das habe ich schon geprüft, d.h. Komponenten kreuzgetauscht, Kabel, Switch getauscht, Box direkt am Router angeschlossen usw.
Am betroffenen Switch hängen 2 PC's, ein Raspberry PI und eine DM800se, da gibt es keinerlei Probleme.
Ich habe auch keine Performance Probleme, wenn die Box im Netwerk ist dann habe ich auch Gbit LAN. Wie gesagt, entweder kommt eth0 nicht hoch oder einzelne sockets sterben beim Bootup. Das jeweilig betroffene socket oder connman über die serielle Verbinung neu zu starten führt JEDESMAL zum Erfolg. Deshalb sind die externen Netzwerkkomponenten mit ziemlicher Sicherheit auszuschließen.
Wenn die Box neu geflasht wurde treten die Probleme nicht oder sehr selten auf, erst wenn man Plugins, kernel-module etc. nachinstalliert hat, fangen die Probleme an. Ich habe auch selbstgebaute .services und .timer im Image, aber es tritt auch ohne diese services Marke "Eigenbau auf". Ich war mir fast sicher, dass systemd beim bootup durcheinanderkommt, je mehr services gestartet werden müssen, deshalb tippte ich erstmal auf ein systemd timing bzw. Abhängigkeitsproblem.
Weil @Reichi gestern in einem anderen Bugreport Threat etwas von wegen "Treiber Probleme kann nicht jeder fixen" gemeint hat, habe ich das ganze mal mit einem 08/15 100Mbit USB/LAN Adapter gestestet:
Edimax EU-4208 (ASIX AX88772B chipset) und dem kernel-module-asix vom feed
onboard NIC eth0 dekativiert und nur eth1 (Edimax) 1:1 wie eth0 konfiguriert. Das hat bisher 50+ reboots ohne Verbindungsfehler mit deaktivieren Network Watchdog überstanden während mit dem konfigurierten eth0 in der selben Umgebung ca. 5-10 mal die Box in ein connection failed bootet oder bestimmte Dienste nicht erreichbar sind (dropbear, telnet, ssh und/oder ftp sockets inactive)
Ich habe das natürlich auf der selben Box mit dem selben Image und unter den selben Netzwerkumgebung und Netzwerkkomponenten getestet. d.h. idente Umgebungsvariablen
50+ reboots haben natürlich keine empirische Aussagekraft, aber das hat das derzeit installierte Image schon lange nicht mehr ohne "connection failed" geschafft.
Zusammengefasst:
* entweder connman oder div. sockets inactiv
* meist hilft ein connman neustart, die sockets neu starten funktionert nur wenn conmann läuft
* im schlimmsten fall das sockets.target neu starten oder box rebooten
* mit einem USB LAN Adapter tritt das Problem bisher nicht auf
* das Problem tritt nur sporadisch auf
Ich habe jetzt schon zig Stunden mit Testen und Infos sammeln verbracht und versucht "Eigenverschulden" so gut wie möglich auszuzschließen - und wie es aussieht bin ich auch nicht alleine betroffenen, aber es scheint nur vereinzelt aufzutreten oder nicht gemeldet zu werden. Ohne "öffentlichen Druck" versandet das klarerweise.
Ich habe mir mittlerweile einen recht zuverlässigen watchdog gebaut der mir zu 99,99% ein stabiles Netzwerk beim bootup beschert.
Aber nach über 8 Monaten und 66 Posts ohne feedback, Vorschläge zur Eingrenzung des Problem eines Dev's - von Lösungsvorschlägen rede ich jetzt nicht mal - habe ich ehrlich gesagt keine Lust mehr.
Ok das du keine Lust mehr hast, kann ich verstehen, ich hätte die Box schon verkauft. Naja mit dem watchdog läuft es zwar, aber das ist ja murks.
Aber ich denke schon, das die meisten Leute eben keine Probleme damit haben, sonst hätte man mehr davon gehört.
Ich wäre am ausrasten wenn mir das passieren würde. Aber das ist mir zum Glück nicht ein einziges mal passiert.
Und ich zeichne SEHR viel auf, und das ausschliesslich auf's NAS. Und die DM900 geht dabei immer wieder in StandBy,
nur am Abend wenn man die Kiste mal verwendet hat, bleibt die an (oder Idle) bis in die Nacht zum EPG Refresh, der schickt sie wieder in StandBy.
Die ganze 5 Köpfige Familie schaut zu 99% nur aufgezeichnetes, dann eben wenn man Zeit dafür hat. Was anderes kann ich mir gar nicht mehr vorstellen.
Ich kann aber Reichi schon verstehen. Wie soll er etwas fixen was NIE bei ihm auftritt ? Wo soll man da anfangen zu suchen ?
Am Ende ist es wieder irgend eine "race condition" wie beim E2 Start Bug den wir mal hatten.
Ich vermutete mittlerweile auch die Treiber als den Schuldigen - was lt. journalctl auffällt:
der asix 3-1:1.0 eth1 Treiber wird vor der Erkennung von lo geladen und die MAC wird korrekt zugewiesen - während das onboard NIC eth0 erst 3 Sekunden später geladen wird
root@dm900uhd:~# journalctl -x|grep "eth\|connman"
Jan 01 01:00:01 dm900uhd kernel: bcmgenet f0b00000.ethernet: GENET 4.5 EPHY: 0x1001
Okt 09 01:08:02 dm900uhd kernel: asix 3-1:1.0 eth1: register 'asix' at usb-f0470300.ehci_v2-1, ASIX AX88772B USB 2.0 Ethernet, 00:50:b6:XX:XX:XX
-- Subject: Unit connman.service has begun start-up
-- Unit connman.service has begun starting up.
-- Subject: Unit connman.service has finished start-up
-- Unit connman.service has finished starting up.
Okt 09 01:08:03 dm900uhd connmand.real[259]: Connection Manager version 1.34
-- Subject: Unit connman-wait-online.service has begun start-up
-- Unit connman-wait-online.service has begun starting up.
Okt 09 01:08:04 dm900uhd connmand.real[259]: Checking loopback interface settings
Okt 09 01:08:04 dm900uhd connmand.real[259]: System hostname is dm900uhd
Okt 09 01:08:04 dm900uhd connmand.real[259]: Failed to open RFKILL control device
Okt 09 01:08:04 dm900uhd connmand.real[259]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
Okt 09 01:08:04 dm900uhd connmand.real[259]: lo {newlink} index 1 operstate 0 <UNKNOWN>
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth0 {create} index 2 type 1 <ETHER>
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth0 {update} flags 4098 <DOWN>
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth0 {newlink} index 2 address 00:09:34:XX:XX:XX mtu 1500
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth0 {newlink} index 2 operstate 2 <DOWN>
Okt 09 01:08:04 dm900uhd kernel: f0b00000.etherne:01: Broadcom BCM7439 (2) PHY revision: 0x10, patch: 1
Okt 09 01:08:04 dm900uhd kernel: f0b00000.ethernet: configuring instance for internal PHY
Okt 09 01:08:04 dm900uhd kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Okt 09 01:08:04 dm900uhd connmand.real[259]: Adding interface eth0 [ ethernet ]
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth1 {create} index 3 type 1 <ETHER>
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth1 {update} flags 4098 <DOWN>
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth1 {newlink} index 3 address 00:50:B6:XX:XX:XX mtu 1500
Okt 09 01:08:04 dm900uhd connmand.real[259]: eth1 {newlink} index 3 operstate 2 <DOWN>
Okt 08 23:47:08 dm900uhd kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Okt 08 23:47:08 dm900uhd connmand.real[259]: Adding interface eth1 [ ethernet ]
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth0 {update} flags 36867 <UP>
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth0 {newlink} index 2 address 00:09:34:XX:XX:XX mtu 1500
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth0 {newlink} index 2 operstate 2 <DOWN>
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth1 {update} flags 36867 <UP>
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth1 {newlink} index 3 address 00:50:B6:XX:XX:XX mtu 1500
Okt 08 23:47:08 dm900uhd connmand.real[259]: eth1 {newlink} index 3 operstate 2 <DOWN>
Okt 08 23:47:08 dm900uhd connmand.real[259]: The name net.connman.vpn was not provided by any .service files
Okt 08 23:47:08 dm900uhd kernel: asix 3-1:1.0 eth1: link down
Okt 08 23:47:09 dm900uhd kernel: libphy: f0b00000.etherne:01 - Link is Down
Okt 08 23:47:10 dm900uhd kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {newlink} index 3 address 00:50:B6:XX:XX:XX mtu 1500
Okt 08 23:47:10 dm900uhd kernel: asix 3-1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {newlink} index 3 operstate 6 <UP>
Okt 08 23:47:10 dm900uhd connmand.real[259]: Skipping disconnect of carrier, network is connecting.
Okt 08 23:47:10 dm900uhd avahi-daemon[247]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.178.90.
Okt 08 23:47:10 dm900uhd avahi-daemon[247]: New relevant interface eth1.IPv4 for mDNS.
Okt 08 23:47:10 dm900uhd avahi-daemon[247]: Registering new address record for 192.168.178.90 on eth1.IPv4.
Okt 08 23:47:10 dm900uhd connmand.real[259]: ipconfig state 3 ipconfig method 1
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {add} address 192.168.178.90/24 label eth1 family 2
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {add} route 192.168.178.0 gw 0.0.0.0 scope 253 <LINK>
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {add} route 192.168.178.1 gw 0.0.0.0 scope 253 <LINK>
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {add} route 0.0.0.0 gw 192.168.178.1 scope 0 <UNIVERSE>
-- Subject: Unit connman-wait-online.service has finished start-up
-- Unit connman-wait-online.service has finished starting up.
Okt 08 23:47:10 dm900uhd connmand.real[259]: eth1 {add} route 21x.xxx.xxx.x5x gw 192.168.178.1 scope 0 <UNIVERSE>
Okt 09 01:08:19 dm900uhd connmand.real[259]: eth1 {del} route 21x.xxx.xxx.x5x gw 192.168.178.1 scope 0 <UNIVERSE>
root@dm900uhd:~#
Alles anzeigen
.
this problem came with OE2.5 update
first ~half~ year with older OE2.? on dm7080sstt i didn't had such problem
after another half year i sent this box to RMA,
but in case they didn't able fix it i received dm900 with Twin DVB-S2
interesting what idiot on DP side decided as customer, who have sent box with four tuners,
will be happy by receive cheaper box and with less count of tuners
Router: MikroTik CRS125-24G-1S-IN
Ethernet cable have seen: dm500 -> dm7020s -> dm800s -> dm8000sstt -> dm7080sstt -> dm900sst
I can neither confirm nor deny
OE2.2 never run on my dm900uhd
@Fred Bogus Trumper Vielen Dank für deinen Ausführlichen Beitrag.
Wir werden uns da auf jeden Fall nochmal Gedanken machen was das sein könnte / wie es dazu kommt / was wir womöglich dagegen tun können.
@Fred Bogus Trumper Hast du es mal mit dhcp statt einer statischen IP probiert?
Ändert sich dann was? Es geht erst mal darum rauszufinden was genau deine Probleme auslöst.
2. Frage: nutzt du immer noch newnigma2? nn2Daemon.socket scheint eine zyklische Abhängigkeit einzuführen.
per DHCP habe ich es noch nicht versucht, vergebe wg. der Orderfreigaben immer eine fixe IP
Ich kann das aber auch mal mit DHCP und fixe IP Zuweisung über die MAC testen
wg. 2
ja, trat aber auch schon im experimental image auf, das ich für einen Gegentest geflasht habe
Den zitierten daeamon habe ich glaube ich auch schon mal disabled und den zugehörigen "Dienst" auf anderem Weg gestartet.
Der laufende deamon liefert(e) Daten über das lokale Netzwerk während ein ssh, telnet Zugriff wg. der inaktiven sockets nicht möglich ist ...
Da aber user in diesem Threat die Probleme bei Verwendung des experimental images bestätigten habe ich das nicht weiter verfolgt.
Ich werde das aber noch einmal testen
nn2Daemon.socket scheint eine zyklische Abhängigkeit einzuführen.
Genauer gesagt entweder nn2Daemon.socket oder onreboot.service.
Alleine an einer statischen IP kann es nicht liegen. Habe ich an meiner 900er schon immer problemlos im Einsatz.
das onreboot.service ist manuell von mir eingebaut und tatsächlich noch aktiv
Ist aber ein nur oneshot der ein script beim bootup einmalig startet und ein file ausliest, das beim shutdown erstellt wurde. Im script sind auch keine Schleifen oder sleeps eingebaut.
Ich bin mir sicher, dass ich das disabled hatte um "Eigenverschulden" auszuschließen. Vermutlich hatte ich das versehentlich wieder aktiviert, als ich ein backup flashte
mal sehen
Sporadisch habe ich auch das Problem (Letztes mal 04.10.18), eigenes Unstable Image, aus der Erinnerung Statisch oder DHCP egal, LAN oder WLAN egal.
Geht man in die Netzwerkkonfiguration, ist da kein Eintrag/Adapter vorhanden.
gruß pclin