SendMail hängt

[flite]

Hallo,

ich verwende den Webservercode von Ulrich für eine Alarmanlage. Zunächst vielen Dank für die viele Arbeit, die du dir damit gemacht hast. Ich habe schon viel an dem Code angepasst, daher ist ein Umstieg auf eine neuere Version schwierig. Ich verwende die Version 1.2.5

Leider kommt es in letzter Zeit immer ab und zu vor, dass eine Email nicht versendet wird und im Anschluss auch keine weitere Email mehr rausgeht. Abhilfe schafft nur ein Reset.

Jetzt habe ich mir den Zustand von der Variable mail_get ausgeben lassen und dieser ist im Fehlerfall dauerhaft auf 1 (statt auf 0).

Ich wollte wissen, ob hier ein bekanntes Problem der Version 1.2.5 vorliegt, oder ob ich mich auf eine ausgiebige Fehlersuche machen muss? Eine Changelog Datei habe ich leider nicht gefunden.

Leider ist die serielle Schnittstelle für ein GSM Modem belegt, so dass ein Debugging über diese nicht möglich ist. Ich konnte leider bisher noch nicht nachvollziehen, in welchen Fällen mail_get auf 1 bleibt. Zumeist funktioniert es nämlich einwandfrei.

Vielen Dank für Eure Mühe.
Steffen

[kendo]

Hallo

war damals erstaunt, dass nicht mehr user dieses Problem feststellen.

siehe mal im diesem Beitrag

http://www.ulrichradig.de/forum/viewtop ... =27&t=1402

gruss kendo

[flite]

Hallo kendo,

danke für Deine Antwort.
Leider ist es bei mir wohl ein anderes Problem. Wenn das Versenden der Mails hängen bleibt, dann bei der Authentifizierung. Die Variable mail_send bleibt dann 1 und mail_send_counter bleibt 4. Da ich mein USART umgebaut habe, ist es etwas schwieriger, an meine Debugmeldungen zu kommen.

Ich lasse mir als nächstes die (wohl falsche) Antwort (den Messagecode) des Servers für die "mail_send_counter=4" ausgeben. Leider funktioniert das Versenden der Mails meistens, so dass es schwierig ist, das Problem zu reproduzieren.

Ich melde mich, wenn ich weitergekommen bin. Falls jemand noch weitere Ideen hat, freue ich mich über eine Nachricht.

Ich habe mir diesen Beitrag schon angeschaut, weil die Symptomatik gleich aussieht und den Beitrag von Marten umgesetzt. Leider hat das auch nicht wirklich geholfen.

http://www.ulrichradig.de/forum/viewtop ... =27&t=1751

Viele Grüße
Steffen

[myjack]

zähl doch einfach eine variable in timer.c runter, wenn mail_send = 1 ist. Wenns zu lange dauert, kannst du so die Funktion wieder auf 0 setzen.

[flite]

Klar - ein Timeout ist eine Möglichkeit. Das ist allerdings meine letzte Wahl, weil ich zum einen schauen möchte, wo wirklich der Fehler begraben liegt und zum anderen im Falle eines Timeouts ja die Email verliere.

Viele Grüße
Steffen

PS: Das Problem ist seit zwei Tagen nicht mehr aufgetreten - allerdings ohne Änderung des Codes. D.h. irgendwann kommt es wieder.

[myjack]

Der Timeout ist m.E. unverzichtbar. Was nach dem Timeout passiert, ist deiner Logik überlassen. Du kannst nach einem Timeout genauso gut den Mailversand erneut anstoßen. Fehlerroutinen sind das A und O

Edith: Dass die mail-send-Funktion hängen bleibt, kann man nie ausschließen. Hier wird immerhin über's Netzwerk eine Kommunikation zu einem fremdem Server hergestellt. Da kann immer etwas schief gehen. Ich habe auch schon mit Mailservern zu tun gehabt, die sich nicht ganz an den SMTP-Standard gehalten haben. Auch da musste ich den Fehler abfangen und handlen.

[flite]

Jetzt lief mein Webserver zwei Tage lang problemlos und gerade eben sollte er wieder eine Statusmeldung versenden. Die Email kam auch an, aber mail_get ist immernoch 1 und mail_send_counter hängt auf 10, was ich sehr seltsam finde, denn bei mail_send_counter = 10 wird ja nur noch folgender Code ausgeführt:
MAIL_DEBUG("\r\n10: Mail wurde versendet!!\r\n");
mail_get = 0;

Er hätte mail_get also zurücksetzen müssen. Aus irgendeinem Grund ist aber die Funktion nicht aufgerufen oder vorzeitig beendet worden.

Um die Timeout Thematik werde ich wohl nicht rumkommen.

Hat hier jemand schon eine bessere Fehlererkennung und -behandlung für den Webserver von Ulrich entwickelt?

Viele Grüße
Steffen

[kendo]

..mail_get ist immernoch 1 und mail_send_counter hängt auf 10, was ich sehr seltsam finde, denn bei mail_send_counter = 10 wird ja nur noch folgender Code ausgeführt:
MAIL_DEBUG("\r\n10: Mail wurde versendet!!\r\n");
mail_get = 0;

Er hätte mail_get also zurücksetzen müssen. ...

Diesen Zustand finde ich nicht seltsam. Siehe in func mail_data ():

--> er sagt aus, dass case 9: statt fand, und dabei mit mail_send_counter++;
der mail_send_counter auf 10 gesetzt wurde.
Was aber nicht bedeutet, dass der case 10 jemals eintraf!!!!
==> daraus lässt sich schliessen, dass die Kommunikation, nach dem case 9:
d.h. senden von "QUIT\r\n", abgebrochen wurde.
Es fehlte also die Antwort des Mailserver, die den case 10: hätte auslösen sollen.

Dieses Verhalten zeigt aber nur die grundsätzliche Problematik mit dieser "Statemachine" auf,
welche in jedem der States (sprich mail_send_counter-Zustand) eintreffen könnte.

Wie Du ja bereits bemerkt hattest, ist eine Überwachung mit timeout unabdingbar!

Danke dass Du auf diesen Punkt hingewiesen hast.
Werde in der nächsten Zeit eine Lösung erarbeiten, da für einen geplanten Einsatz meinerseits notwendig.

ÜBRIGENS: hatte ich ein ähnliches Problem zu lösen:

Fällt der Chip enc28j60 aus, hängt das ganze in einer Warteschlaufe (never ending loop) fest, irgend wo im nachfolgenden Gebilde der func eth_get_data().
Die restliche Funktionalität z.B. Alarmanlage, Heizungs-Steuerung etc. sollte aber weiterlaufen trotz Ausfall, des Netzwerkanschlusses (in unserem Falle: Ausfall des enc28j60)

Melde mich...

Gruss Kendo

P. S.
hier ein Beispiel der Kommunikation.
Im obigen Fall fehlte wohl die die Message 221 vom Server
--------------------------------------------------------------------------------------------------------------
220 Welcome to the @Mail SMTP Server ( Exim / 25 )
helo hs1
250 mail02.nexlink.ch Hello zux221-211-253.adsl.green.ch [81.221.211.253]
mail from: xx@3soft.ch
250 OK
rcpt to: xxx@reitschule-interlaken.ch
250 Accepted
data
354 Enter message, ending with "." on a line by itself
Hallo das ist meine meldung
.
250 OK id=1NHg64-000822-TX
quit
221 mail02.nexlink.ch closing connection