Bugfix/fix slave does not gracefully close sockets - #162
Conversation
alisitsyn
changed the title
|
Hello, rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT) HMI connects here (192.168.1.86 polling 2 input registers at approx. 1,000ms...) I (4235) port.utils: Socket (#55), accept client connection from address[port]: 192.168.1.86[52071] 2nd client connects here (PC 192.168.1.120 running Mosbus Poll software - polling 2 holding registers at approx. 80ms) I (10215) port.utils: Socket (#56), accept client connection from address[port]: 192.168.1.120[59633] 2nd client disconnect here (PC 192.168.1.120) E (20145) mb_port.tcp.slave: 0x3ffbfc44, node #1, socket(#56)(192.168.1.120), communication fail, err= -11 I (2100715) MB_TCP_SLAVE: INPUT READ: offset=0 type=8 size=2 Reconnected 2nd client at 192.168.1.120 here..... W (2106505) mb_port.tcp.slave: 0x3ffbfe88, node #2, socket(#57)(192.168.1.120), handling time [ms]: 974, exceeds slave response time in master. Thank you. |
|
Hello, @MD-Richards, Thank you for report. Your logs will help to fix the issue. This fix is simple but applies to many scenarios and should be tested adequately. I remember I saw this already during first testing. I see that the race condition happens on slave after disconnection. Unfortunately, I can not return to this immediately but I will do this ASAP. |
|
I have same phenomenon. please visit my repo. https://github.com/jnlee4838/ss_modbus_tcp_sht4x. if you look at the WireShark capture, it (ESP32 Modbus Slave) transmits "ACK" back to Master about "FIN". it should have transmitted "FIN" to Master back immediately and waited for the final ACK from Master for graceful disconnect. instead, it starts to transmit "KEEPALIVE"...Finally "RST" signal like "E (xxxxx) mb_port.tcp.slave: 0x3ffbfc44, node #0, socket(#55)(192.168.0.2), communication fail, err= -11" |
|
Thanks for your report and log. I can reproduce this and it looks strange. I will continue with investigation of this issue but am pretty busy. I will inform you once the solution is found. |
c5f69fa to
f96b106
Compare
|
I think the issue is fixed. PTAL to updated fix in the branch and help to test on your side. Thanks. |
f96b106 to
aebac6f
Compare
aebac6f to
ca8027a
Compare
|
I have 2 devices polling the slave every 5 seconds:
After missing to respond to the 1st device the slave enters a cycle of I'm using the esp-modbus component from |
|
@ram-bt , Please try to not exceed the value of Try again and this would make the issue more clear. |
Alex when you mention the Let me make the changes and get back to you. Thank you. |
|
ram-bt,
The |
ca8027a to
c165252
Compare
Alex when you say not to exceed the value of 3S (i have set the response timeout for slave as 3S) Does this mean that i should be respecting the same on the master side right? |
|
@ram-bt ,
The requirement Example connection settings of ModbusPoll (on my side): I will try to reproduce your issues with Modscan as well a bit later. Could you also try the ModbusPoll and check if the issue remaining? |
|
Understood Alex. Let me make the changes and get back to you |
4 participants
Description
This PR fixes the issue when the TCP master connects to the slave, sends the data, disconnects then repeat this cycle. The TCP slave is not able to process the disconnection event correctly and does not gracefully close sockets (when master send FIN packet to slave).
Related
#161 (EPROT-55)
#138 (EPROT-4)
#140 (EPROT-5)
Test results
The TCP slave updated and is able to close connection from master immediately when receive the FIN packet. All other possible errors are processed with timeout to allow the master to repair connection.
It is possible to communicate with slave using the TCP master which uses
connect - send request - disconnectflow.The communication reliability is increased significantly due to improvements in event handlers. The race conditions are possible in case of incorrect response time configuration. The users need to respect the response time option and need to calculate this properly for their multi-master environment.
Communication log with four modbus tcp masters connected to one esp_tcp_modbus_slave over wifi. Masters set with response time = 1000ms (causes the race condition after some time), then changed to 1300ms. Each master reads four types of registers. Max calculated response time for request = 38ms.
wifi_4_tcp_masters_to_tcp_slave_resp_time=1000_then_1300_conn_disconn.log
Checklist
Before submitting a Pull Request, please ensure the following: