DNS_CLIENT or IP_CONFIG problem

[Strucc]

Hi,

I used the logic in the demo programs to build world weather functionality in my application. However, I figured out, that after a while and some queries the communication stops: no further queries are possible. The error code is 16#00FFFF00 / a DNS error. So, I separated a sample DNS test program:

PROGRAM PLC_PRG
VAR
   strHost      :   STRING   :=   'www.bme.hu';

   IP_C        :   IP_C;
   S_BUF       :    NETWORK_BUFFER;
   R_BUF       :    NETWORK_BUFFER;
   IP_CTRL      :    IP_CONTROL;

   DNS_CLIENT   :   DNS_CLIENT;
END_VAR

IP_CTRL (
   IP_C       :=    IP_C,
   S_BUF      :=    S_BUF,
   R_BUF      :=   R_BUF,
   TIME_OUT   :=   T#5s,
   IP         :=   DWORD_OF_BYTE(10,1,2,1)
);

DNS_CLIENT (
   IP_C       :=    IP_C,
   S_BUF      :=    S_BUF,
   R_BUF      :=   R_BUF,
   DOMAIN      :=   strHost
);


After starting the program and triggering variable DNS_CLIENT.ACTIVATE, the query was successful. But, the next query (reset and set ACTIVATE) failed with timeout. After some investigation with the IP?C structure, I noticed, that IP_C.C_MODE does not reset to 0 - after doing this, another DNS query was possible...

So without further and deeper investigations, I added the following quick fix to solve this:

DNS_CLIENT line 118:

99:   R_BUF.SIZE := UINT#0; (* Empfangslänge rücksetzen *)
   ip_state := BYTE#4; (* Abmelden *)
   IP_C.C_MODE := 0;
   state := 00;

It seems to work fine, but I don't know, if it's correct... Ideas?

[peewit]

can you give me your test program with the error

on which system do you work ?
which version of the libraries you use ?

[Strucc]

It's CoDeSys 2
X-Soft Codesys by Microinnovation - Moeller - Eaton
Platform XV-101

The library versions are the latest:
codesys_network_112.lib
oscat_basic_332.lib

The test program above produces the error itself: as described for the second ACTIVATE event (I do this directly in Online mode, by changing the ACTIVATE value TRUE / FALSE). Do you need a project export?

[peewit]

hello strucc

The network.lib 1.12 is tested with Codesys 2.3.9.25 and Codesys SP PLCWinNT v2.4 and WAGO 750-841

on these platforms, there is no problem

I think this problem is present only on your hardware

your solution probably works randomly
but if it solves your problem, then make it so

[Strucc]

Did you try to run the above test program in itself?

The preogram in the DEMO folder works fine for me as well.

And in my application, there was no trouble, when other FBs (HTTP_CLIENT, SNTP_CLIENT) were using IP_C as well - they reset the status themselves. But somehow, DNS_CLIENT does not.

[peewit]

Your test program works without any problems (Codesys SP PLCWinNT v2.4 and WAGO 750-841)

you can make the test with Codesys SP PLCWinNT v2.4 (soft-plc) ?

[arsh0r]

In my case the DNS_CLIENT kind of got caught in state 30. IP_C never gave an Error and the FB has no Timeout like FTP_CLIENT does.
i helped myself with this workaround:

Code Auswählen Erweitern


30: IF IP_C.ERROR <> DWORD#00 THEN
ERROR := IP_C.ERROR;
state := 99;
        (*####################  DEBUG-MESSAGE  ###################################*)
        (*IF _debug_enable THEN
            LOG_CL.NEW_MSG := 'DNS: S30 ERROR ~1';
            LOG_CL.PRINTF[1]  := DWORD_TO_STRING(ERROR);
            LOG_MSG();
        END_IF;*)
        (*########################################################################*)
ELSIF NOT ACTIVATE THEN (* WORKAROUND WORKAROUND WORKAROUND WORKAROUND*)
state := 99; (* WORKAROUND WORKAROUND WORKAROUND WORKAROUND*)
ELSIF (S_BUF.SIZE = UINT#0) AND (tid = R_BUF.BUFFER[1]) AND (R_BUF.SIZE >= INT_TO_UINT(34 + url_length)) THEN (* prüfe ob antwort telegramm die richtige Transaction-ID und mindestlänge hat *)
ERROR := BYTE_TO_DWORD(R_BUF.BUFFER[3] AND BYTE#2#0000_1111); (* prüfe Return code der Flags. 4 bits *)
IF ERROR = DWORD#00 THEN
anc := R_BUF.BUFFER[7]; (* Anzahl der Answer-RR *)
IP_C.R_OBSERVE := FALSE; (* Datenempfang ueberwachen *)
state := 40;
ELSE
state := 99;
END_IF;
END_IF;

i think DNS_CLIENT needs some kind of timeout or reset

[peewit]

hallo

prinzipiell sollte der imp_control immer die fehlermeldungen produzieren
und mittels timeouts die abläufe überwachen

welchen version des ip_control ist hier in verwendung ?
wir haben erst vor ein paar wochen nochmals die network.lib für codesys nachgebessert
lade dir nochmals die neueste version runter, und binde sie ein


mache wieder deine tests mit den original bausteinen
wenn es wieder probleme gibt, würde mich ein wireshark mitschnitt sehr interessieren, von dem zeitpunkt wo der
dns_client ausfällt

[arsh0r]

habe die IP_Contol aus der codesys_network_hf1 mit version 1.9   vom 26. Feb. 2012. Datenpakete mitschneiden wird schwierig. Im Anhang ist habe ich einen Screenshot von der Bausteininstanz wenn sie hängt.

[gelöscht durch Administrator]

[arsh0r]

Hängt sich der DNS_CLIENT evtl. auf, weil der IP_C1 im FTP_CLIENT doppelt verwendet wird? zuerst für Namensauflösung und danach für den FTP Steuerkanal. Wenn die FTP Verbindung an einem blöden Zustand wegen Timeout abbricht...?

[peewit]

das der doppelt verwendet wird, ist absicht, damit man speicher spart
im prinzip sollte immer vom ip_control eine fehlermeldung kommen

was bei dir hier passiert gilt es heraus zufinden !
deine lösung behebt zwar die problem , aber nicht die ursache

das beste wäre hier natürlich ein datenmitschnitt

[arsh0r]

ich versuche das morgen nochmal durchzuspielen wie der Baustein in die missliche Lage kommt...
Wann liefert der IP_CONTROL denn einen ERROR wegen Empfangsüberwachung?
Der FTP_CLIENT muss den DNS_CLIENT irgenwie abgewürgt haben sonst wäre der C_ENABLE nicht auf FALSE, denke deswegen greift auch keine Überwachung.
Der DNS_CLIENT kommt von alleine nicht mehr aus der Sache Raus.
evtl. könnte man das so schreiben:

Code Auswählen Erweitern


(* Domain Name System (query) *)

IF ACTIVATE AND NOT activate_last THEN (* auf positive Flanke GET warten *)
DONE := FALSE;
ERROR := DWORD#0;
state := 5;
END_IF;

CASE state OF

05: IP4 := IP4_DECODE(str:=DOMAIN); (* prüfe ob domain schon eine IP4-Adresse ist *)
...

dann würde der Baustein auf jeden Fall neu anfangen wenn eine Flanke auf ACTIVATE kommt.

[peewit]

das grundproblem steckt im ip_control
hier passiert etwas was nicht mit einer fehlermeldung erkannt wird
das gilt es zu finden und zu beheben.
alle anderes lösungen sind und bleiben workarounds

ziemlich alle anderen bibliotheken verwenden die dns-client funktion des betriebsystems.
wir benutzen natürlich (plattformunabhängig) unseren eigenen dns_client
aber das sollte alles kein grund für irgendein problem sein


wenn es wieder mal stehen bleibt wären screenshots von dem variablen der ip_control instanz ziemlich wichtig
wireshark wäre auch gut, aber wenn du es nicht machen kannst, dann eben nicht ....

ich werde die zum wochenende eine ip_control version geben, die debug_meldungen ausgibt
dann finden wir eventuell das problem schneller. ...

[peewit]

hallo arsh0r

entferne mal deine workarounds und benutze den ip_control im anhang
dieser erzeugt debug_meldungen in den globalen variablen in der network.lib

nachdem der fehler wieder aufgetreten ist, schaust du bei den globalen variablen nach (wie im bild im anhang)
und machst eine bildschirmhardcopy dieser datenstruktur
dazu wäre auch dein variablen dump vom ip_control ganz gut !



[gelöscht durch Administrator]

[arsh0r]

habe ich letzten Freitag eingespielt und seither warte ich darauf das es wieder passiert...
Bei den zwei Wago Cpus mit denen ich getestet habe trat der Fehler das letzte mal nach 1-3 Tagen auf. damals hatte ich auch ein Problem mit meinem FTP Server. warten wir mal ab...