Netzwerkprobleme bei Dauerbetrieb

[hobbit]

Hallo

Wir haben auf dem RevPi Core eine Python Anwendung entwickelt. Diese implementiert einen RADIUS Server, sowie einen OPC Server zu dessen Administration.
Die Anwendung konfiguriert beim Start die Netzwerkschnittstelle im DHCP Client Mode und erhält dann vom DHCP Server eine IP. Anhand dieser IP wird das Subnet ermittelt, in welchem sich das Gerät befindet. Anhand dieser IP wird dann von der Anwendung eine statische IP konfiguriert. Nun startet der OPC Server sowie der RADIUS Server und das Gerät läuft im Dauerbetrieb. Im Endsystem befinden sich bis zu 7 Geräte in unterschiedlichen Subnets. Während des Betriebs versucht jedes Gerät die anderen Geräte aus den verschiedenen Subnets anzupingen, um festzustellen, welche Geräte vorhanden sind.
Mittlerweile gab es Rückmeldungen von diversen Kunden, welche Geräte im Einsatz haben, dass nach ein paar Tagen Dauerbetrieb der RevPi nicht mehr via Netzwerk erreichbar sei. Ich konnte das Problem bei mir mittlerweile reproduzieren. Die Situation trifft bis jetzt nach 1 - 10 Tagen ein.

Status:
Die Ausgabe auf dem RevPI (nach Ping-Versuch) zeigt "connect: Network is unreachable".
pi@RevPi ~$ ifconfig -a:

• eth0 vorhanden

• UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

• keine IP (inet addr) zugewiesen

gemäss /var/log/syslog und "dmesg" ist eth0 "up"

Die Situation löst sich leider nicht von selbst auf. Ein Neustart der Netzwerkschnittstelle (pi@RevPi ~$ sudo /etc/init.d/network restart) löst das Problem, bis es nach einiger Zeit wieder auftritt.
Auffällig ist, dass das Syslog und "dmesg" zeigt, dass eth0 zyklisch den Link beat verliehrt und nach 1-2s wieder detektiert. Dies geschieht teilweise mehrmals hintereinander im 10 Sekunden-Takt und dann wieder für ca. 45 min nicht mehr.
Meldung in syslog:

• RevPi kernel: [xy] smsc95xx 1-1.1:1.0 eth0: link down

• RevPi ifplugd(eth0)[4908]: Link beat lost.

• RevPi kernel: [xy] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xD1E1

Setup Entwicklungsumgebung (bei mir):
pi@RevPi ~$ uname -a
Linux RevPi 4.1.13-rt15+ #4 PREEMPT RT Mon Aug 8 14:46:27 CEST 2016 armv61 GNU/Linux
DHCP-Server: Mikrotik RB2011
Spannungsversorgung: Steckernetzteil

Setup bei Kunden:
Teilweise neuere RevPis, da erneut bestellt. Jedoch alles RevPi Core 1.
DHCP-Server: Siemens Industrial
Spannungsversorgung: Hutschienen-Netzteil

Hab auch den Post "Netzwerkschnittstelle verabschiedet sich bei Langzeitzugriffen" mitverfolgt. Es scheint irgendwie in die selbe Richtung zu gehen.

mfg Christian

[Eduard]

Hallo Christian,

als erstes würde ich mit „sudo apt-get update und sudo apt-get upgrade“ alle verfügbaren Packetupdates installieren.
Wenn das nicht hilft, dann versuch bitte das Jessie Image auf den RevPi zu flashen.
Denn soweit ich weiß wird der Core 1 mit dem Wheezy Image ausgeliefert.

Damit wir den Fehler im System finden brauchen wir die kern.log Datei, bitte stelle uns diese zur Verfügung.

[RevPiModIO]

Hi Christian, hast du denn im kern.log auch die "eth0: unregister ..." / "eth0: register ... " Meldungen, wie hier?

Ich hab den Fehler total vergessen, wir arbeiten bei uns aber auch nur noch mit Core3 RevPis. Als ich jetzt meinen Schaltschrank vom Revolutionsumbau wieder aufstellte und nach ein paar Tagen am Panel die Meldung "OFFLINE" gelesen habe, kam alles wieder hoch

Auch nach apt-get .... alles aktualisieren, ist das Problem noch immer da. Wie gesagt, Core1 Produktion vor 08.2017 (und auch, die ich da zum Testen damals austauschte hatten das Produktionsjahr).

Gefühlt (!) hatte es damals auch etwas mit Netzwerkauslastung usw zu tun, aber Gefühle können falsch sein...

Um den Fehler jetzt endlich mal einzugrenzen werde ich in meinen Revolutionsumbau einen Core3 mit exakt selben Setup usw. einbauen und damit mal testen...

Gruß, Sven

[hobbit]

Hallo zusammen

Danke für eure Antworten.
Ja, die selben Zeilen wie bei Sven's Post stehen auch in meinem kern.log.
Noch zur Info bezüglich zusammenhang mit dem USB-Controller: Aktuell hab ich eine USB-Tastatur und ein Monitor via HDMI angeschlossen. Das Problem tritt aber auch auf, ohne dass irgend ein USB oder HDMI Gerät angeschlossen ist. Nur Netzwerkverbindung zum Gerät. So ist auch der Einsatzzweck des Geräts beim Endkunden.

Im Anhang hab ich das aktuelle kern.log und syslog angefügt. Um ca. 12:22 Uhr hab ich den Netzwerk-Interface Neustart durchgeführt, damit ich wieder auf den RevPi zugreifen konnte.

Ich werd nun mal die vorgeschlagenen Updates für Wheezy durchführen und dann wieder warten, bis das Problem allenfalls erneut auftritt. Das kann dann allenfalls einige Tage dauern.

[hobbit]

Updates haben nichts gebracht. Das Problem ist bereits wieder aufgetreten.
Versuchs nun mit dem Jessie Image.

[RevPiModIO]

Ich hab das Jessie Image vom 22.09.2017 bei mir auf dem Core1 und Core3... Den Core am Revolutionsumbau habe ich am Sonntag gegen den Core3 getauscht... Parallel lasse ich den Core1 auch mit Jessie vom 22.09.2017 bei mir laufen...

Noch läuft es... Warten wir ab...

Generell ist es aber eine gute Idee auf Jessie umzusteigen... Verstehe eigentlich nicht wirklich, warum der Core 1 noch mit Wheezy verschickt wird, das ist wirklich oldold mittlerweile

Gruß, Sven

[Ingo]

Hi,

also ich arbeite hier auch noch mit einem Core1 und dieser ist schon seit 1Jahr im Dauereinsatz. Ok wir haben als erstes die Einträge in der Netzwerk Config geänder. Der DHCP Dienst wurde ausgeschaltet da der Core feste IP Adressen hat.
eine für ETH0 und eine für ETH1 (Virtuell)
Unter dem Altem Wheezy oder auch dem jetzigen Jessie gab es noch keine Ausfälle im Netzwerk. Vieleicht solltes du das ganze einmal mit Festen IP Adressen versuchen, es kann sein wenn der DHCP neue IP Adressen vergeben will das genau da der PI hängen bleibt. Auch hatte der Core1 als er Ausgeliefert wurde eine WLAN Konfiguation enthalten die wir auch entfernt haben da es diese nicht gab.

[hobbit]

Hab gestern das Jessie Image aufgespielt, dann die Updates laufen lassen (sudo apt-get update, sudo apt-get upgrade) und dann den RevPi über Nacht in der unveränderten Konfiguration (DHCP Client Mode) laufen lassen. Bis jetzt ist er immernoch erreichbar. Aber was mich bereits wieder irritiert: Wieso tritt laut kern.log "eth0: link down / eth0: link up" im ca. 10min Takt auf? Ist das normal? Siehe Anhang.

@Ingo: Danke für deine Ausführungen. Wie in meinem Ausgangspost ersichtlich, wird der RevPi nur in der Aufstart-Phase im DHCP-Client Mode betrieben. Anschliessend wird eine statische IP konfiguriert. Dies ist durch das Anwendungs-Scenario gegeben.

Werde nun wieder alles für meine Anwendung konfigurieren (wie auf Wheezy) und dann schauen, ob das Problem wieder auftritt.

[Eduard]

Hallo Christian,

ich konnte bei meinen RevPis so ein Phänomen nicht feststellen.
Wie lange ist das Ethernet Kabel? Kannst du diesen vielleicht zur Prüfung gegen ein anderes tauschen?

[hobbit]

Es handelt sich um ein neues LINDY Cat.6 S/FTP Patch Cable, 2.0m, Klasse E.
Versuchs nun noch mit einem anderen..