Meine Ethersex-Installation zur Abfrage diverser 1Wire-Sensoren , S0-Stromzähler und Inputs lief hier seit ca. 5 Jahren problemlos Seit ca. 3 Wochen hängt sie sich allerdings alle 1-2 Tage auf, ist über Telnet nicht mehr erreichbar. Komischerweise geht ein Ping aber weiterhin. Ich bin etwas ratlos, wo ich hier anfangen soll zu suchen? Evtl. ein 1wire-Sensor feucht geworden? Ich frage die Sensoren von einem Linux-Server z.B. mit garagentor=`echo '!pin get in4' | nc 192.168.178.44 2701 -q 1 2>/dev/null ` ab. Wie kann ich vom Server aus feststellen ob sich der Ethersex aufgehangen hat? Ping geht leider wie gesagt, sonst wäre es einfach Viele Grüße Klaus
Hallo Klaus, ich hatte diese Probleme auch mal. Letztendlich war bei mir der ENC28J60 auf dem NET-IO defekt. Nach dessen Austausch lief alles wieder. Gruß Bodo
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
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?
Hallo Klaus, der Fehler lässt sich doch insofern eingrenzen das Dein netio nicht mehr erreicht wird. garagentor=`echo '!pin get in4' | nc 192.168.178.44 2701 -q 1 2>/dev/null ` ab. Ich würde mir mal das Netzteil und die Spannungsversorgung anschauen, falls Du hast - natürlich mit Oszilloskop. Enc hast Du schon getauscht. Steckernetzteil schon getauscht? Hast Du das netio selber gelötet? Falls ja alle Lötstellen in Ordnung? Tippe persönlich aber auf die Spannungsversorgung und die Elkos. Gruß Sven
Klaus schrieb: > garagentor=`echo '!pin get in4' | nc 192.168.178.44 2701 -q 1 > 2>/dev/null ` ich würde erst mal testweise das 2>/dev/null hier wegnehmen. Möglicherweise spuckt netcat ja eine erhellende Fehlermeldung aus, die Du so einfach ins Nirwana schickst. U.u. kann ein zusätzliches "-vv" beim nc-Aufruf noch Infos bringen.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.