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?
Etwas Off-Topic, aber: Mit was hast Du dem Stack die Datenpakete gesendet? Ein spezielles Testprogramm? Gruß, Thomas
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...
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.