The Industrial Raspberry Pi Forum

Hallo,
ich beobachte folgendes Verhalten bei einem Testaufbau mit 6 konfigurierten MODBUS TCP-Mastern (konfiguriert mittels PiCtory):
Alle 6 Master bauen eine Verbindung zu 6 verschiedenen Slaves auf und lesen zyklisch 11 Register aus. Zyklisch werden die 6 Modbus_Master_Status-Register ausgelesen. Soweit alles OK (alle 0).
Jetzt wird ein MODBUS TCP-Slave beendet. Ab jetzt steht im Modbus_Status_Register vom ersten Master 0x11 (der, wo der Slave nicht mehr vorhanden ist). In den 5 anderen Modbus_Master_Status-Registern steht jetzt der Wert 0xFF (die Slaves sind aber noch alle da). Nach einer Weile (ca. 2 Minuten) beendet sich der Prozess piModbusMaster (läuft im Vordergrund eines Terminals) auf dem RevPi mit lh_table_new: calloc failed. Ich hatte auch schon einen Segmentation fault beobachtet.
Ich frage mich warum die Status-Register der nicht betroffenen Slaves auf 0xFF gehen und warum der Master-Prozess abstürzt. Er wird auch nicht wieder automatisch neu gestartet.
Kann da jemand etwas zu schreiben?

Hallo noch mal,
nach ein paar Tagen Pause habe ich mir heute noch einmal das Verhalten der MODBUS-Status-Register angesehen. Der Fehler lag bei mir. Wenn ein Slave nicht erreichbar war oder ein anderer Fehlercode ausgelesen worden ist, habe ich mittels C-Funktion piControlReset(); den Treiber zurückgesetzt und danach direkt weiter Status-Register abgefragt. Direkt nach dem Reset liegen in den Registern aber noch keine Informationen vor (deshalb 0xFF). Jetzt warte ich nach dem Reset ein paar Sekunden und es verhält sich alles wie es soll Eine Frage hätte ich aber jetzt noch: Wie lange sollte man nach piControlReset(); warten? Gibt es da eine festgelegte Mindestdauer oder die Möglichkeit den Reset-Status des Treibers auszulesen?

Viele Grüße,
Jörg

Edit: Allerdings stürzt der Prozess piModbusMaster bei den Tests ab und zu immer noch ab
Edit2: Es sieht so aus, als ob zyklisches Aufrufen von piControlReset(); den Prozess zum Abstürzen bringt

Es gab da einen Hotfix Upstream in der lib modbus, die wohl verwendet wird, allerdings in einer älteren Version. Es gibt wohl bestimmte MODBUS Devices die die Lib zum crashen bringen. Vielleicht kann das mal jemand verifizieren. Stichwort VD-1301 vulnerability.

https://nvd.nist.gov/vuln/detail/CVE-2019-14463