SMTP Baustein Network Lib Fehler

Begonnen von klaus1, 11. Mai 2011, 22:00:13

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 2 Gäste betrachten dieses Thema.

peewit

priorität hoch ?

von was
und warum willst du das einstellen

mike_roh_soft

Moin,

ich denke er meinte die Priorität der Email damit ein rotes Ausrufezeichen im Outlook o.ä. erscheint.

peewit

ich denke das diese priorisierung kein bestandteil der smtp basis ist
momentan ist mir nicht klar durch was man das mitteilen kann

hier müssten wir mal untersuchungen anstellen , wie das funktioniert ....


mike_roh_soft

Habe das nur eben Überlfogen:
http://office.microsoft.com/de-at/outlook-help/hervorheben-wichtiger-e-mail-nachrichten-mit-prioritatskennzeichen-HA001192162.aspx

Denke mal kann an den Clients einstellen das PRIO"hoch" in einen bestimmten Ordner kommt und das dann den User signalisiert er muss das lesen!

Eigentlich NonSense!

skateman

Hallo!

Ich habe auch das Problem, dass ich nur mails versenden kann, wenn ich die IP-Adresse von mail.gmx.net-Server angebe (z.B. 213.165.64.20). Bei Verwendung des Namens "mail.gmx.net" bekomme ich die Fehlermeldungen ERROR_T=1 und ERROR_C=FF00

Ich habe den google.dns ( 8.8.8.8 ) als DNS_IP4 eingetragen. Ich habe testweise auch auf der Beckhoff CX diesen DNS angegeben und konnte dann von der CX problemlos mail.gmx.net pingen. Dann müsste die IP doch eigentlich auch aus der SPS-Runtime heraus richtig aufgelöst werden, oder?

lG



peewit

#35
so pauschal ist es schwierig hier zu antworten


1. der fehler bedeutet das keine korrekte antwort empfangen bzw erkannt wurde !

2. welche programmiersoftware/sps-hardware verwendest du
3. welche lib versionen verwendest du (basic , network version)
4. welche netzwerkeinstellungen werden seitens der sps verwendet
5. was ist dein internetzugang, und wie angebunden

6. stelle ein kleines testprogramm online, bei dem es nicht funktioniert, dann kann ich damit testen
    optional könntest du dein testprogramm auf eine DNS_CLIENT Abfrage reduzieren
    denn das sollte eigentlich auch schon nicht funktionieren
7. optimal wäre noch ein wireshark mitschnitt vom datenverkehr





skateman


ad 2.) ich verwende TwinCAT mit einer CX9001
ad 3.) OSCATBasic v.3.33 / OSCATNetwork 1.21
ad 4.) SPS hat fixe IP-Adresse und Gateway eingetragen (testweise auch 8.8.8.8 als DNS)
ad 5.) SPS hängt auf einem UMTS-Router
ad 6.) Testprogramm muss ich nicht hochladen, da ich das selbe Verhalten auch mit der SMTP_CLIENT_DEMO habe
aus dem DNS_CLIENT FB bin ich irgendwie nicht schlau geworden. Ich habe ihn getestet, allerdings bekomme ich kein Ergebnis - weder DONE wird true noch ändert sich der ERROR-Zustand
ad 7.) kann ich derzeit nicht anbieten, da ich keinen HUB zur Verfügung habe

An den Einstellungen des Routers kann es auch nicht liegen, da ich mit den selben Einstellungen (Fixe IP, Gateway, DNS 8.8.8.8 ) von meinem Laptop über diesen Router mittels Outlook und den selben SMTP-Einstellungen Mails absetzen kann.

peewit

#37
hallo

den dns_client baustein musst du mit einer ip_control instanz verbinden , ansonsten passiert gar nichts
(der smtp-baustein hat diesen schon includiert)

probeweise kannst du mal als smtp-server z.b. "www.oscat.de" nehmen
man kann zumindest sehen ob dann dieser dns-namen aufgelöst werden kann
dann sollte auch eine andere fehlermeldung austauchen

alternativ könntest du noch andere udp_client bausteine probieren
wie z.b. SNTP_Client, un zu sehen ob es ein prinzipielles problem seitens udp telegrammen gibt.


ansonsten sind keine neuen informationen dabei, damit ich die unmittelbar noch tips geben kann


skateman

habe den DNS_CLIENT Baustein jetzt richtig mit dem IP_CONTROL verwendet un bekomme die selbe Fehlermeldung FF00.

Daher brachte auch die Änderung des SMTP-Server Namens wieder die selbe Fehlermeldung.

Was ich nicht verstehe ist, dass direkt unter WinCE auf der CX die DNS-Namen richtig aufgelöst werden --> es funktioniert z.B. auch der Aufruf aus dem Internet-Explorer.


peewit

das sind zwei paare schuhe

die sps kann zb ohne die nachträgliche installation der tcp-server ce bibliothek überhaupt nicht auf das netzwerk zugreifen
dadurch ist hier noch eine zusätzliche abstraktionsschicht vorhanden

dns abfrage wird beim ping , explorer etc vom betriebssystem übernommen
in unserem fall machen wir die komplette dns-abfrage nur über die sps (baustein dns_client)
und nutzen keinen code vom betriebssystem !
hier sind wiederum zwei völlig verschiedene programme am arbeiten


was du aber machen könntest ist das du als dns-server deinen arbeits-pc angibst, und diesen dann wireshark laufen lässt
dann müsstest du zumindest die dns-anfrage sehen
wenn nicht, dann gibt es ein schwerwiegendes problem, das gar nichts nach aussen gelangt

skateman

#40
hallo,

nach längerer zeit habe ich mich jetzt wieder mit der dns_client geschichte beschäftigt. inzwischen habe ich mit den ip-adressen gearbeitet.

habe jetzt als test mal die ip-adresse meines arbeits-pcs als dns-adresse angegeben (10.10.100.66) und in wireshark mitgeschnitten.

wie man im anhang sehen kann, scheint als source-adresse 192.168.0.1 auf.

der beckhoff cx9001 hat ja 2 netzwerk-controller. der 1. controller hat die ip-adresse 10.10.100.1, auf welchem auch die generelle daten-kommunikation abläuft. der 2. controller hat eben die 192.168.0.1, welcher aber nur für die ethercat-kommunikation dienen sollte. aus irgendeinem grund versucht der dns_client die abfrage über den 2. controller durchführen zu wollen, was natürlich nicht funktioniert - aufgrund des ip-ranges wäre es normalerweise logisch, dass der controller 1 verwendet wird.
wenn ich statt des domain-namens die ip eingebe, kommt vom nachfolgenden baustein (in diesem fall http_get) der aufruf auch richtigerweise von 10.10.100.1!

kann man das verhalten irgendwie beeinflussen?

lG
Roland

[gelöscht durch Administrator]

peewit

#41
hallo


habe ich dich richtig verstanden

die dns abfrage per udp-protokoll auf zielport 53 wird über netzwerk-controller 2 durchgeführt
die http abfrage per http-protokoll auf ziel port 80 wird über netzwerk-controller 1 durchgeführt
(zumindest der quell-ip nach , dürfte es so sein)


skateman


peewit

#43
die ethernet kommunikation läuft über den installierten TCP/IP Connection Server

ich habe schon vielleicht mögliche ursache und lösung entdeckt

gib mir zeit bis zum wochenende dann kann ich dir eventuell eine test-version geben.....

skateman

super - wäre sehr dankbar für eine lösung!