Ethersex hängt sich auf, aber Ping geht?

Hallo Bodo,

danke für den Tipp, dann werde ich den mal als erstes tauschen und 
hoffen :-)

Ich hole das alte Thema noch mal hoch - der Tausch des ENC hat leider 
nichts gebracht, der Net-IO mit Ethersex hängt sich weiterhin alle 1-2 
Tage auf.

Ich überwache ihn momentan vom Server aus, habe eine schaltbare 
STeckdose dazwischen
Strom aus/an für 10 sec reicht aus, um ihn wieder zum Leben zu erwecken

Irgendwelche weitere Ideen?


Viele Grüße

Klaus

In 
https://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin
heisst es u.a.

> 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

Besonders die fehlenden Cs am ENC hatten bei vielen, (auch bei meinem) 
den Verlust der Kommunikation bewirkt. Nachruesten der Cs behob das 
Problem.

Nein, die sind auf der Leiterplatte nicht vorgesehen.
Und sie wurden wahrscheinlich vergessen, weil sie nicht in der 
Beispielschaltung im Datenblatt gezeichnet sind, nur im Text erwaehnt.

wendelsberg

ping wird vom Kernel selbst beantwortet, für die meisten anderen 
Aufgaben, z.B. telnet, muss erst ein Programm gestartet werden. Wenn 
z.B. die Festplatte komplett ausfällt, geht ping immer noch. Programme, 
die schon laufen und keine Festplattenzugriffe machen, laufen auch 
weiter.

Ein beliebter Fehler: ein Programm verbraucht im Laufe der Zeit immer 
mehr Speicher. Dann können irgendwann keine neuen Programme mehr 
gestartet werden, der Rest läuft aber noch. Eigentlich müsste eine 
bestehende telnet-Verbindung weiter funktionieren inkl. der Shell. 
Welche Befehle man noch ausführen kann, hängt natürlich vom Fehler ab. 
Shell-interne wie pwd oder echo sollten immer noch gehen.

eagle user schrieb:
> ping wird vom Kernel selbst beantwortet, für die meisten anderen
> Aufgaben, z.B. telnet, muss erst ein Programm gestartet werden. Wenn
> z.B. die Festplatte komplett ausfällt, geht ping immer noch. Programme,
> die schon laufen und keine Festplattenzugriffe machen, laufen auch
> weiter.

Das ist ein AVR-Netio, der hat keine Festplatte.

wendelsberg

> 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

die habe ich drin, das Teil lief ja auch schon 2 Jahre, dann kam der 
Fehler plötzlich


Ich schicke mit mit Ehersex u.a. direkt zu einer 
Volkszähler-Installation bei einem Webhoster. Kann es evtl. sein das 
hier was nicht angenommen wird und sich Ethersex deshalb aufhängt?


Viele Grüße

Klaus

Klaus schrieb:
> Kann es evtl. sein das
> hier was nicht angenommen wird und sich Ethersex deshalb aufhängt?

Moeglich, weil auf so einem kleinen uC der Pufferspeicher nicht gross 
sein kann. Kannst Du nur durch Mitloggen sicher ausschliessen.

wendelsberg

Hallo Wendelsberg,

wie kann ich das mitloggen?  Mir fällt spontan nur Wireshark ein, ist 
aber ein RIesen-Aufwand mit Ntzwerkhub usw
Oder gibt es bei Ethersex eine einfachere Möglichkeit?

Viele Grüße

Klaus

Ich denke da auch an Wireshark.

wendelsberg

Klaus schrieb:

> Ich schicke mit mit Ehersex u.a. direkt zu einer
> Volkszähler-Installation bei einem Webhoster. Kann es evtl. sein das
> hier was nicht angenommen wird und sich Ethersex deshalb aufhängt?

Natürlich.

Ethersex verwendet nur einen ganz primitiven Netzwerkstack mit vielen 
Restriktionen und wenig Automatismen.

Es ist Sache der Anwendungen, diesen Stack korrekt zu benutzten. 
Insbesondere ist es Sache der Anwendungen, TCP-Verbindungen in 
Fehlersituationen (auch auf höheren Protokoll-Layern) korrekt 
abzuräumen, indem im richtigen Moment die richtigen Funktionen des 
Stacks aufgerufen werden.

Deine Fehlerbeschreibung klingt ganz danach, als würde deine Anwendung 
genau dies nicht tun, also keine korrekte Fehlerbehandlung 
implementieren, sondern nur den Fall abbilden, dass alles so läuft, wie 
es idealerweise laufen sollte. Sprich: eine typisches C-Programm von 
typischen C-"Programmierern", die eigentlich im Wesentlichen nur 
Copy&Paste betreiben...

Das führt dann hier dazu, dass längst abgekackte Verbindungen 
speicherverwaltungtechnisch im Stack offen bleiben. Irgendwann (eher 
früher als später) ist dann das Limit der vom Stack unterstützten 
gleichzeitigen TCP-Verbindungen ausgeschöpft. Das führt dann unmittelbar 
dazu, dass der Stack selber zwar sehr wohl noch läuft, aber keine 
TCP-Verbindungen mehr aufbauen kann, weder aus- noch eingehende. D.h.: 
ICMP und ARP gehen noch (sprich: "ping geht"), aber z.B. telnet 
eingehend ist nicht mehr möglich, weil telnet halt auf einer 
TCP-Verbindung aufsetzt, die der Stack nicht mehr anbieten kann, weil 
alle verfügbaren ausgeschöpft sind.

Also: lerne, wie die verwendeten Protokolle funktionieren, lerne, wie 
der Stack sie umsetzt, und gestalte dann deine Anwendung so, dass sie 
ihn auch in Fehlersituationen korrekt benutzt...

Das Zauberwort heißt: LERNE

Du hast die optimalen Voraussetzungen, weil du den kompletten Quelltext 
des Stacks einsehen kannst und auch die Spezifikation aller verwendeten 
Protokolle ohne Zwangsabgaben an irgendeine Abzocker-Organisation frei 
verfügbar sind.

Solche phänomenal guten Voraussetzungen werden heutzutage leider immer 
seltener...

>Also: lerne, wie die verwendeten Protokolle funktionieren, lerne, wie
>der Stack sie umsetzt, und gestalte dann deine Anwendung so, dass sie
>ihn auch in Fehlersituationen korrekt benutzt...

Ich habe eigentlich nur die bereits in Ethersex implemtierte Funktion 
für den Volkszaehler genutzt, den Ethersex-Quelltext zu analysieren und 
zu verbessern übersteigt leider meine Kenntnisse bei weitem

komisch, das es 3 Jahre funktioniert hat, es kann ja jetzt alles 
mögliche sein, von irgendwelchen gealterten Elkos im Netzteil bis zu 
o.g. Fehler in Ethersex / Änderungen beim Webhoster

Aber das herauszufinden, ich glaube da tue ich mich einfacher das Ganze 
durch was Neues zu ersetzen?

Schon länger her, hatte aber ein ähnliches Problem. Es lag dann an der 
Initialisierung des enc. Die enc-init-routine von ulrich radig führte 
dann zu stabilen  Ergebnissen.