The Industrial Raspberry Pi Forum

Übrigens, mittlerweile hat sich auch das Netzwerk wieder verabschiedet. Das passiert, weil sich 'usb 1-1.0' disconnected. Und da das der Root-Hub ist, an dem alles andere hängt -- u. a. das Netzwerkinterface, ist es natürlich auch vorbei mit der Netzwerkkommunikation zum 'Wago 750-352'.
Tja, jetzt muss ich mir überlegen, was ich mit dem RevPi mache. So, wie er sich hier verhält, würde ich ihn als defekt bezeichnen. Dabei geht es jetzt noch gar nicht um die Verwendung der nach außen geführten USB Ports! Sondern nur um die Verwendung des Ethernets...!
Hast du noch irgendwelche Ideen?

Man darf natürlich USB nutzen. Am besten dafür, wofür es entwickelt wurde: HMI. Also Maus, Tastatur, USB CAM, Monitore, usw. Das alles funktioniert auch tadellos mit einem Raspi oder mit unserem RevPi. Aber wenn man anfängt und die typischen TTY-Applikationen (also über einen FTDI realisierte UART-Schnittstellen, die über USb kanalisiert werden) zu nutzen, um einen vernünftigen Feldbus zu ersetzen, dann muss man auch mit den typischen Problemen leben. Es gibt nur wenige stabile Treiber die wir kennen, die solche Verbindungen problemlos im Dauerbetrieb offen halten können. Das hat weder etwas mit unserer oder der Raspi HW zu tun, noch mit den Kerneltreibern, die USB Basisfunktionen bereitstellen. Es hat meist immer etws mit den spezifischen Gerätetreibern zu tun, die oft keine Hotplug-Fähigkeit besitzen und deshalb bei der kleinsten Störung auf der USB Leitung aussteigen.
Und Störungen auf USB sind ein absolut übliches Phänomen. Die in der EN 61131 geforderten Tests für Feldbusse (Über Koppelzangen eingekoppelte starke EMI) kann USB wegen viel zu kleiner Signalpegel bei zu hoher Geschwindigkeit und mangelnde Abschirmung der Kabel, sowie i.d.R. kein verdrilltes Datensignaladerpaar nicht überstehen. Das Signal bricht gnadenlos weg und in der Regel bedeutet dies ein Reconnect, genau wie bei einem Hotplug. Für HMI Devices ist das überhaupt kein Problem. Die fehlenden Daten (es gibt keine ausreichenden Datenkorrekturmechanismen für solch massive Störungen im USB Protokoll) sind hier ja kein Thema. Aber bei UART basierten Anwenderprotokollen könne solche Störungen sehr oft vom Treiber nicht gehandhabt werden und der entsprechende Agent oder Demon, der die Daten entgegen nimmt und verarbeitet hängt sich dann auf. das alles hat rein gar nichts mit unserer HW oder der vom Original Raspi zu tun, sondern ist ein bekanntes Problem wegen dem industrielle Anwendungen keine Steuerungsdaten über USB übertragen, sondern dafür geeignete Feldbusse verwenden.
leider ist nun beim Broadcom SoC keine Ethernetschnittstelle vorhandne und daher hat Raspi damals den Weg gewählt, die vorhandene USB Schnittstelle zu nutzen, um über einen USB zu Ethernet Bridge Baustein Ethernet bereitzustellen. Dies führt dann dazu, dass bei einem Treiber-Neustart der USB Kerneltreiber auch die Ethernetschnittstelle betroffen ist. Hier kann es dann u.U. dazu kommen, dass diese Schnittstelle nicht selbstheilend wieder korrekt angefahren wird. Wenn bei Dir aber nun die Reduzierung der Ehternetverbindung auf 10 Mbit das Problem gelöst hat, so war die Ursache eben gerade nicht dieses Phänomen und wir brauchen dann nicht analysieren, warum sich bei Dir der USB Treiber von selber sporadisch neu startet.
Der Wegfall der Probleme bei Reduktion auf 10 Mbit deutet dann vielmehr auf ein generelles Netzwerkproblem mit 100 Mbit. Die USB-Anbindung ist nicht in der Lage einen vollen 100 Mbit Datendurchsatz auf Ethernet zu verarbeiten. Wenn ein Datendurchsatz in dieser Höhe konsequent gefahren wird, kommt es vermutlich in der USB zu Ethernet Bridge zu einem Bufferoverflow, der möglicherweise einen Reset der Ethernetverbindung herbeiführt. das ist aber erst einmal eine pure Mutmaßung. Bei dem von Dir beschriebenen Datenverkehr (ein paar wenige Modbusregister werden 10 mal pro Sekunde ausgelesen) würde sich weit unterhalb der 10 Mbit bewegen und sollte für die Schnittstelle kein Problem darstellen.
Typische andere Ursachen für Störungen bei 100 Mbit sind marode Stecker oder Kabel. ich gehe davon aus, dass Du die Kabel sicher schon mal ausgetauscht hast, um diese Ursache auszuschließen.

Ich will hier keine Grundsatzdiskussion vom Zaun brechen. -- Da ich als Applikationsingenieur täglich mit vielen(!) Anwendern weltweit zu tun habe, die problemlos USB Verbindungen in der industriellen Messtechnik einsetzen, kannst du dir vielleicht vorstellen, dass ich mit deinen Ausführungen nicht d'accord gehe. Wenn USB "nur" oder "vor allem" für HMI da wäre, gäben insbesondere die höheren Datenübertragungsraten von USB 2.0 und USB 3.x <Ironie> ganz besonders viel Sinn </Ironie> !! Und warum du hier mit einer Feldbus Norm auf USB schießt, verstehe ich auch nicht. Aber, um es nochmal zu betonen: Darum geht jetzt auch gar nicht. -- Das Netzwerk meines RevPi funktioniert nicht zuverlässig. Und, wie schon erläutert, hat die Option smsc95xx.turbo_mode=N in /boot/cmdline.txt NICHTS gebracht. Im Moment will ich einfach nur über ein (nagelneues, doppelt geschirmtes) Cat 7 Kabel mit einer Länge von 50 cm kontinuierlich alle 100 ms sechs 16-bit Modbus Register lesen und schreiben, und zwar über eine dauerhaft offene TCP Verbindung auf Port 502. Und das alles in einem modernen Büro neben meinem PC-Arbeitsplatz. Nicht einmal diese Anforderung ist mit meinem Revolution Pi länger als ein paar Stunden möglich. Deshalb wiederhole ich meine Behauptung, dass sich der (zumindest mein) Revolution Pi nicht für Langzeiteinsatz eignet.

Ich habe mal geschaut, welche Jessie Version ich installiert habe. Das ist das Image von 2017-06-01, das ich am 2.7. von eurer Supportseite heruntergeladen hatte. Vorhin habe ich erneut euer ZIP des Jessie-Images herunter geladen, und da ist jetzt ein Image vom 7. August drin?! Leider steht in den ReleaseNotes nichts über den Vergleich der beiden Versionen. Hat sich da vielleicht bezgl. der USB disconnect Problematik und/oder Netzwerk-Probleme etwas geändert? Dergestalt, dass es sich lohnen würde, das System neu aufzusetzen?? Ansonsten würde ich dich bitten, dass du mir mitteilst, an wen ich mich bezgl. RMA für mein System wenden kann, damit das bei euch in einen brauchbaren Zustand gebracht wird.

Viele hundert User setzen den RevPi Core professionell, industriell und gewerblich ein. Sehr viele von ihnen verwenden den RevPi Core mit CM1 und verwenden TCP/IP Datenverkehr im 24/7 Stunden Betrieb. Ich würde gerne versuchen, auch Deinen Anwendung irgendwie zum stabilen Laufen zu bringen. Aber das setzt voraus, dass wir gemeinsam nach allen möglichen Ursachen suchen. Wir müssen bei der Sachlage (bei hunderten von Usern sowie bei uns im Labor funktioniert etwas, was bei Dir nicht funktioniert) davon ausgehen, dass die Ursachen in dem speziellen Anwendungsfall liegen, würden aber immer auch nicht ausschließen, dass hier noch ein Bug in der Software vorliegt, der sich eben nur unter sehr besonderen Umständen bemerkbar macht.Du betonst immer wieder Deine Kompetenz und möchtest daher den Fehler zwingend im RevPi ansiedeln. So werden wir aber der Ursache nicht auf den Grund gehen können. Ich habe das Gefühl, dass Du und unser RevPi nicht so recht zusammen passen. Wahrscheinlich bist Du mit einem anderen Produkt besser bedient. Daher schlage ich vor, Du sendest uns Dein Gerät zurück (bitte zu Händen Dr. Volker de Haas) und wir erstatten Dir den Kaufpreis. Wir wünsche uns zufrieden Kunden und wenn uns das nicht gelingt, dann bedauern wir dies sehr.

Darf ich mit mit diesen Logzeilen hier mal mit anschließen

Ich habe bei meinem Revolutionsumbau das selbe Problem. Hardware: RevPi Core 1 mit ersten veröffentlichten Jessie Image plus allen Updates. Das Netzwerk läuft keine 24 Stunden. Ich habe mich dann mal direkt mit Monitor, Maus und Tastatur angeschlossen und gesehen, dass die Netzwerkschnittstelle keine IP mehr hatte. Da dachte ich es liegt an unserem DHCP Server. Seit gestern habe ich eine feste IP konfiguriert und dhcpcd deaktiviert. Durch diesen Beitrag wurde ich dann hellhörig und schaute mal ins kern.log:
Die Netzwerkschnittstelle kommt zwar wieder, aber wird nicht konfiguriert...

Gruß, Sven

PS: Ich werde mal das aktuellste komplett Jessie Image auf das Gerät flashen.

Volker, ich will den Fehler nicht im RevPi ansiedeln, sondern ich will ihn in diesem/meinem RevPi ansiedeln. Genausowenig wie ich deine Kompetenz anzweifle, wäre es schön, wenn du meine Kompetenz akzeptieren könntest. Nach 35 Jahren in diesem Beruf als Entwicklungs- und Applikationingenieur darfst du mir einfach glauben, dass ich --wie du-- schon viele solcher Probleme zu lösen hatte. Und wir wollen doch das Gleiche, nämlich dass der Revolution Pi in möglichst allen Einsatz-Szenarien stabil und fehlerfrei läuft. Und wenn ein System eine Netzwerk- und ein paar USB-Schnittstellen bietet, dann musst du akzeptieren, dass jemand (wie ich ) selbige einfach nur verwenden will. Hinterher, wenn Probleme auftauchen, mit Argumenten zu kommen, man solle die Schnittstellen am besten nur für ganz bestimmte Zwecke (...die WER definiert?) einsetzen -- das, lieber Volker, stößt bei mir in der Tat auf taube Ohren. Wenn das tatsächlich dein/euer Plan ist, dann schreibt das in eure Datenblätter und Unterlagen auch so rein... Und wenn nicht, dann nimm das Problem bitte Ernst und schreibe mir nicht ständig nur "....das muss aber gehen, weil es bei anderen auch geht".

Das einzige, was bisher an Vorschlägen kam, war der 'turbo_mode' Parameter des 9512 Treibers. Den hatte ich, wie du dich erinnerst, schon vorher auf 'N' gestellt gehabt, und der hatte letztendlich keine Änderung des Verhalten bewirkt. Ich hatte gefragt, was der Unterschied eurer Jessie Images von Anfang Juni und Anfang August ist; und ob ein "Update" ggfs. Besserung bringen könnte?! Falls du noch weitere/andere Vorschläge hast, werde ich diese gerne aufgreifen/ausprobieren. Von der Applikationsseite her kann ich sagen, dass ich keine "Schweinereien" mache, und die Applikation ja auch seit 10 Jahren vor Ort im realen Einsatz stabil ist. Da wüßte ich nicht, was ich ändern sollte, außer, die TCP Verbindung ständig zu öffnen und wieder zu schließen. Das würde zwar die Toleranz bezgl. der re-connects in der USB Schicht erhöhen, aber der dauernde TCP Auf- und Abbau wäre halt verdammt "teuer".

Tja, und für den Fall, dass dir sonst auch nichts anderes mehr einfällt, hatte ich eben gefragt, wohin ich meinen RevPi zur Überprüfung schicken kann. -- Was ich mich auch frage, ist, ob ein Umstieg/Upgrade auf die Core 3 Version vielleicht etwas brächte...? Was meinst du? Du kennst die HW sicher besser als ich...!?!

Danke für deine bisherigen Bemühungen. Ich kann verstehen, dass du mich als Anwender, der dir Arbeit und Kopfzerbrechen bereitet, weil er Probleme meldet und anspricht, los werden willst. Wenn das die Art der Problemlösung im vorliegenden Fall sein soll, muss ich das akzeptieren. Im anderen Fall freue ich mich auf weitere Vorschläge...

Ich habe dir dazu in einer PM geantwortet.

Halo Sven,
um die Ursachen einkreisen zu können hier ein paar Fragen / Bitten vom linux-Team:
Wenn der Fehler auftritt, könntest Du bitte mal ifconfig-a eingeben und die Antwort posten?
Wird das Ethernet-Interface aufgelistet?
Heißt es eth0 oder hat es eine andere Nummer gekriegt und heißt jetzt z.B. eth1?
Wird es mit "UP" aufgelistet oder ist es down?
Hat es eine IP-Adresse konfiguriert?
Was passiert wenn man es manuell mit ifup hochfährt, kriegt es dann eine IP-Adresse und kann wieder nach außen kommunizieren?

Nur mal so aus der Hexenküche: Der Compact wird ja eine unabhängige zweite Ethernetschnittstelle bekommen und ich höre gerade, dass der Kerneltreiber dann so schöne Sachen wie Bonding der Interfaces zu einem hochverfügbaren Interface erlauben wird, einschließlich Lastverteilung und Priorisierung, alles mit den Linux-Bordmitteln
das wird noch sehr spannend, vor allem wenn zwei Compacts zusammengeschaltet werden und wir eine echte System-Redundanz über ein Heartbeat-Signal (per dediziertem Ethernetkanal) ermöglichen können...

Hi Volker und jdg!

@jdg: Bezüglich des 24/7 oder industriellen Einsatz kann ich dich beruhigen Auf Wheezy-Basis haben wir RevPi-Cores mit DIO und Modbus-Gateway bereits an die Asphaltindustrie geliefert. Darauf läuft unser Datenlogger (auch hier im Forum vorgestellt) in Python3 geschrieben mit unserem RevPiModIO Modul. Die Daten werden jedoch nicht auf einen USB-Stick geschrieben (wie im Forum vorgestellt) sondern über das Netzwerk an einen Server gesendet. Die Teile laufen 24/7 wobei der Erste Anfang März in den Produktiveinsatz ging.
Aber, sowohl du als auch der RevPi an meinem Revolutionsumbau verwenden ein älteres Jessie Image. Ich habe mein System gestern auf das aktuellste Jessie vom 07.08.2017 hochgezogen und komplett neu eingerichtet. Bis jetzt ist der Fehler bei mir nicht wieder aufgetreten, bin gespannt wie es bei dir aussieht.

Der RevPi vom Revolutionsumbau war damals (Februar bis April) ebenfalls Wheezy und lief 24/7. Über unser RevPiPyPLC-System wurde er auch immer brav erreicht. Daher tippe ich in Richtung Software?

@volker: Die "eth0" Schnittstelle war nach dem Ausfall wieder da, auch mit dem Namen "eht0", da ich auf den DHCP-Server aus dem Netzwerk drüben tippte habe ich die Kiste dummerweise einfach neu gestartet :S
ABER: Wie oben geschrieben läuft nun das neuste Jessie auf dem RevPi und bis JETZT 29 Stunden nach Start gab es keinen Ausfall mehr!
Für kontinuierlichen Netzwerkverkehr sorgt unser PanelPC, der mit der Netzwerkversion von RevPiModIO im 50 Millisekundentakt das Prozessabbild ließt und teilweise schreibt...

Warten wir einfach mal ab Ich melde mich morgen! Schönen Feierabend erst einmal!

Gruß, Sven!

Hallo Sven,

danke für deine Informationen. Es hört sich in der Tat beruhigend an, zu lesen, dass du mit dem August Image anscheinend ein besseres/stabileres Verhalten hast. Dann mache ich den Versuch vielleicht doch noch (es ist nämlich immer ein ziemlicher Aufwand, alle unsere Software auf einer neuen Distribution aufzusetzen.)

Ich bin mittlerweile ziemlich sicher zu wissen, wie es zum Netzwerk-Totalverlust kommt. Das ändert aber nichts an der primären Ursache, dass die USB Verbindung zum 95xx (wahrscheinlich 9512) aus ungeklärter Ursache wegbricht, zum Beispiel:

[Wed Aug 23 22:26:31 2017] usb 1-1.1: USB disconnect, device number 14
[Wed Aug 23 22:26:31 2017] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet
[Wed Aug 23 22:26:31 2017] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Wed Aug 23 22:26:31 2017] usb 1-1.2: USB disconnect, device number 15
[Wed Aug 23 22:26:31 2017] usb 1-1.2.3: USB disconnect, device number 19
[Wed Aug 23 22:26:31 2017] usb 1-1.2.4: USB disconnect, device number 20
[Wed Aug 23 22:26:31 2017] usb 1-1.2.4.7: USB disconnect, device number 22
[Wed Aug 23 22:26:31 2017] Indeed it is in host mode hprt0 = 00001101
[Wed Aug 23 22:26:32 2017] usb 1-1: reset high-speed USB device number 2 using dwc_otg
[Wed Aug 23 22:26:32 2017] Indeed it is in host mode hprt0 = 00001101

Danach kommt das USB Subsystem wieder:

[Wed Aug 23 22:26:32 2017] usb 1-1.1: new high-speed USB device number 23 using dwc_otg
[Wed Aug 23 22:26:32 2017] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[Wed Aug 23 22:26:32 2017] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[Wed Aug 23 22:26:32 2017] smsc95xx v1.0.4
[Wed Aug 23 22:26:33 2017] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet, c8:3e:a7:00:0a:97
[Wed Aug 23 22:26:33 2017] usb 1-1.2: new high-speed USB device number 24 using dwc_otg
[Wed Aug 23 22:26:33 2017] usb 1-1.2: New USB device found, idVendor=0409, idProduct=005a
[Wed Aug 23 22:26:33 2017] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[Wed Aug 23 22:26:33 2017] hub 1-1.2:1.0: USB hub found
[Wed Aug 23 22:26:33 2017] hub 1-1.2:1.0: 4 ports detected
[Wed Aug 23 22:26:33 2017] usb 1-1.2.3: new high-speed USB device number 25 using dwc_otg
[Wed Aug 23 22:26:33 2017] usb 1-1.2.3: New USB device found, idVendor=1a40, idProduct=0201
[Wed Aug 23 22:26:33 2017] usb 1-1.2.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Wed Aug 23 22:26:33 2017] usb 1-1.2.3: Product: USB 2.0 Hub [MTT]
::
::

...und auch das Netzwerk-Interface ist kurz darauf wieder da:

[Wed Aug 23 22:26:37 2017] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[Wed Aug 23 22:26:37 2017] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[Wed Aug 23 22:26:39 2017] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[Wed Aug 23 22:26:39 2017] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Und wenn man jetzt genau auf die Zeiten achtet, sieht man, dass das Netzwerk wieder zur Verfügung steht, der DHCP aber ein paar Sekunden vorher schon aufgegeben hat, weil er keinen Carrier hatte:

Aug 23 22:26:32 RevPi100102 dhcpcd[467]: eth0: deleting default route via fe80::209:4fff:fe85:348c
Aug 23 22:26:32 RevPi100102 dhcpcd[467]: eth0: deleting route to 200344f:6d00::/64
Aug 23 22:26:34 RevPi100102 dhcpcd[467]: eth0: deleting address fe80::83a4:c306:fd35:a44f
Aug 23 22:26:34 RevPi100102 dhcpcd[467]: eth0: deleting route to 192.168.1.0/24
Aug 23 22:26:34 RevPi100102 dhcpcd[467]: eth0: deleting default route via 192.168.1.244
Aug 23 22:26:34 RevPi100102 dhcpcd[467]: eth0: removing interface
Aug 23 22:26:35 RevPi100102 dhcpcd[467]: eth0: adding address fe80::83a4:c306:fd35:a44f
Aug 23 22:26:35 RevPi100102 dhcpcd[467]: eth0: waiting for carrier
Aug 23 22:26:35 RevPi100102 dhcpcd[467]: eth0: removing interface
Aug 23 22:26:35 RevPi100102 dhcpcd[467]: eth0: deleting address fe80::83a4:c306:fd35:a44f

Somit bleibt schließlich das eth0 in einem "adresslosen" Zustand zurück, und man hat keine Chance mehr (weder intern noch von extern), mit dem System per Netzwerk zu kommunizieren:

pi@RePi100102:~ $ ifconfig -a
eth0 Link encap:Ethernet HWaddr c8:3e:a7:00:0a:97
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28062 errors:0 dropped:63 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2176926 (2.0 MiB) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5538 errors:0 dropped:0 overruns:0 frame:0
TX packets:5538 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:713926 (697.1 KiB) TX bytes:713926 (697.1 KiB)

pi@RePi100102:~ $ ifquery --state -a
lo=lo

pi@RePi100102:~ $ ifup eth0
ifup: failed to open lockfile /run/network/.ifstate.lock: Permission denied

pi@RePi100102:~ $ sudo ifup eth0

pi@RePi100102:~ $ ifquery --state -a
eth0=eth0
lo=lo

pi@RePi100102:~ $ ifconfig -a
eth0 Link encap:Ethernet HWaddr c8:3e:a7:00:0a:97
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28298 errors:0 dropped:63 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2195905 (2.0 MiB) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5538 errors:0 dropped:0 overruns:0 frame:0
TX packets:5538 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:713926 (697.1 KiB) TX bytes:713926 (697.1 KiB)

Das einzige, was jetzt hilft, ist ein DHCP Restart:

pi@RePi100102:~ $ sudo systemctl restart dhcpcd.service

und siehe da -- es ist wieder da:

pi@RePi100102:~ $ ifconfig -a
eth0 Link encap:Ethernet HWaddr c8:3e:a7:00:0a:97
inet addr:192.168.1.220 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 200344f:6d00:e980:8b7:97c9:b378/64 Scope:Global
inet6 addr: fe80::521:e403:ee83:2566/64 Scope:Link
inet6 addr: fda7:231a:493e:0:b4d1:323a:50b6:14ff/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1075226 errors:0 dropped:64 overruns:0 frame:0
TX packets:1042840 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:57623107 (54.9 MiB) TX bytes:83269608 (79.4 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5538 errors:0 dropped:0 overruns:0 frame:0
TX packets:5538 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:713926 (697.1 KiB) TX bytes:713926 (697.1 KiB)

Das ist natürlich alles recht und schön, aber die laufende Applikation hat klarerweise den Verlust ihrer I/O Schnittstellen bemerkt und die Überwachungsfunktion terminiert. Und was soll der Kunde mit einer DVB-T Senderüberwachung, die nicht überwacht...?!!?

Danke für deine Hilfe, Sven!
Viele Grüße
Jürgen