Hallo zusammen,
nach einem Langzeittest habe ich festgestellt, dass mein Stack nicht
mehr reagierte. Nach 8,5 Mio empfangenen Datenpacketen hat der Stack
einfach die Verbindung gekappt und reagierte danach auch nicht mehr auch
Verbindungsversuche oder ICMP (Ping). Der Rest des Programmes lief
jedoch munter weiter. Was kann das sein? Kann da evtl der ENC28J60 (mein
Ethernetchip) Schuld sein? Hab leider vergessen mal den Resetpin auf Low
zu siehen am ENC. Das werd ich morgen dann mal testen...
Jemand noch ne andere Idee?
Hmm. Mich würde auch interessieren wem der Stack sagt, dass er aufhören
soll zu senden wenn ich uip_stop() sage.
Also angenommen ich bin auf einen Port connected und dann kommt eine
Homepageanfrage auf Port80 und dort wird ebenfalls connected, wem sagt
dann uIP er soll aufhören zu senden wenn ich uip_stop() ausführe?
Verdammt. Das interessiert mich aber jetzt schon stark.
Wie kann ich, während ich Daten, die auf einem Port empfangen wurden,
verarbeite, dem anderen Port sagen (bzw. dessen Client dahinter), dass
er aufhören soll daten zu senden?
josefk(_nologin?) wrote:
> wem sagt> dann uIP er soll aufhören zu senden wenn ich uip_stop() ausführe?
Na deinem Verbindungspartner, wem sonst?!
Ich vermute mal, dass das einer der ENC28J60 Bugs ist. Kann das sein?
Alternativ könnte auch der Mikrocontroller abgestürzt sein, oder oder
oder...
josefk(_nologin?) wrote:
> Verdammt. Das interessiert mich aber jetzt schon stark.>>> Wie kann ich, während ich Daten, die auf einem Port empfangen wurden,> verarbeite, dem anderen Port sagen (bzw. dessen Client dahinter), dass> er aufhören soll daten zu senden?
mit uip_stop()? Dann wird ein TCP Paket mit einer Window-Size von 0
Bytes gesendet. Wenn du uip_resume() (oder so?!) aufrufst, wird das
Receive Window wieder geöffnet und die Daten strudeln wieder rein.
Ich empfehle dringends dir Netzwerkgrundlagen anzueignen.
Schicke ich damit ein "stop" an alle Ports oder an den, der als letztes
ein Packet gesendet hat?
Ich konnte aus dem Manual auch ncht herauslesen, was genau in
uip_appdata steht. Angenommen ich verarbeite gerade ein Packet und
während dessen schickt mir jemand von Port80 aus Daten und jemand anders
von Port90 aus. Damit landen beide Packet im Buffer des ENC. Dann,
irgendwann, liest meine main-schleife diese Daten aus dem Buffer. Wird
dann von uIP aus 2 mal in die "Statemachine", also die von mir
angegebene Funktion UIP_APPCALL, mit dem jeweiligen Portinfos
gesprungen, oder nur einmal mit dem von Port80?
Ich habe auch die Erfahrung gemacht, dass uIP+ENC28J60 nach einiger Zeit
(etliche Tage bis ein paar Wochen) erst zäh wurde, dann überhaupt nicht
mehr reagierte.
Ich hatte bei den betreffenden System allerdings die Freiheit, es
täglich neu starten zu können. Seither hatte kein Problem mehr.
Ich hatte dann zunächst nur eine tägliche Reinitialisierung vom uIP
eingebaut, das hat aber nichts eingebracht. Seither wird der komplette
Controller neu gestartet.
Aha. Na dann bin ich nicht der einzige :)
Der Port 80 wird mit nem HTML-Interpreter (Firefox) gefüttert und Port90
ist ein eigenes kleines Testprogramm mit C# gemacht, dass einfach nur
permanent daten abfrägt. Funktioniert immer ziemlich lange einwandfrei,
doch plötzlich geht der Stack eben nicht mehr.
@Andreas Kaiser
wie hast du den Hardwarereset realisiert? Keine ahnung, wie ich meinen
Controller alle paar Tage resetten soll....
Besser währ natürlich, wenn das durchliefe
josefk(_nologin?) wrote:
> wie hast du den Hardwarereset realisiert?
Interrupts ausschalten, Watchdog mit kürzester Frist einschalten,
bischen warten und ab geht die Reise. Dran denken, dass sich der
Watchdog durch den Reset nicht unbedingt abschaltet, also ggf. im
Startup vorneweg selber abschalten wenn sonst nicht gebraucht.
Möglicherweise reicht es auch, den ENC zu resetten. Oder was auch immer.
Ich hatte das Problem nicht allzu tief verfolgt sondern benötigte eine
schnelle sichere Lösung, weil ja nur zäh reproduzierbar und Weg dorthin
zu weit.
Hmm. Ich bin mir nicht sicher, ob mir ein Watchdog weiter hilft. Mein
Stack reagierte einfach nicht mehr auf Anfragen. Die Hauptschleife wird
aber weiterhin permanent durchlaufen. Ich wüßte also garnicht wo ich nen
WD-Reset einfügen sollte.
Mir ist aufgefallen, dass der Stack, wird er permanent von einem Port
aus bombardiert, langsamer wird. Deutlich langsamer! Sobald aber die
Gegenstelle einen reconnect macht, normalisiert sich alles wieder...
josefk(_nologin?) wrote:
> Schicke ich damit ein "stop" an alle Ports oder an den, der als letztes> ein Packet gesendet hat?
Du schickst ein Zero Window Size Paket an den Verbindungspartner des
Sockets! Mensch.. Alles andere wäre doch Quark.
Woher weißt du denn, dass es am uip liegt? Hm? Wie gesagt, der ENC28J60
hat auch Macken bzgl. Hängenbleiben!
josefk(_nologin?) wrote:
> Hmm. Ich bin mir nicht sicher, ob mir ein Watchdog weiter hilft.
Der Watchdog sorgt bei mir nachts um 2:00 für einen Restart vom
Controller. Wenn du also eine Uhrzeit hast, such dir einen passenden
Zeitpunkt. Wenn nicht, zähl die Laufzeit mit und lass ihn nach einigen
zig Stunden die Runde drehen. So das in der Anwendung zulässig ist.
Nur aus Interesse: falls der Controller per WD zurückgesetzt wird, wird
dann beim Startup auch der ENC* per Hardwarepin "reseted". Falls dem
nicht so ist, wäre das Problem auf den Controller bzw. die Firmware
einzugrenzen und nicht auf den ENC*.
Also ich habe das Ding mal über die Nacht laufen lassen. Nach 24Mio
Antworten wurde die Verbindung zum CLient unterbrochen. Irgendwas ging
also nicht mehr. Nach einem Reset des ENC ging wieder alles. Schätze
also es liegt einzig am ENC. Der scheint sich irgendwie voll zu müllen.
Naja. Soll mir recht sein. Mit einer neuen Initialisierung des ENC kann
ich leben. :)
josefk(_nologin?) wrote:
> Also ich habe das Ding mal über die Nacht laufen lassen. Nach 24Mio> Antworten wurde die Verbindung zum CLient unterbrochen. Irgendwas ging> also nicht mehr. Nach einem Reset des ENC ging wieder alles. Schätze> also es liegt einzig am ENC. Der scheint sich irgendwie voll zu müllen.> Naja. Soll mir recht sein. Mit einer neuen Initialisierung des ENC kann> ich leben. :)
Kurze Frage: Welche ENC28J60 Sourcen benutzt du? Zufällig meine? Hm...
@Simon K
Ja. :)
Bin mir aber nciht mehr sicher woran es wirklich liegt. Ein Testprogramm
(nicht von mir geschrieben) wird immer langsamer und stribt irgendwann.
Mein Programm scheint normal weiter zu laufen. Genau weiß ich aber
nicht. Hab keine Zeitfunktion eingebaut. Damn. Muss ich wohl machen...
