TCP Master: fails to reconnect to slave using IP after ethernet reconnect (EPROT-62) #167

Activity

1. espressif-bot

   added

   Status: Opened

   on Apr 7, 2026
2. github-actions

   changed the title [-]TCP Master: fails to reconnect to slave using IP after ethernet reconnect[/-] [+]TCP Master: fails to reconnect to slave using IP after ethernet reconnect (EPROT-62)[/+] on Apr 7, 2026
3. alisitsyn commented on Apr 10, 2026

   

   alisitsyn

   on Apr 10, 2026

   Last edited by alisitsyn

   Collaborator

   More actions

   @ram-bt ,

   Thank you for this report.

   MB TCP Master should automatically recover after ETH link loss and reconnection

   I agree with you and remember I was testing this and this aspect was working just fine in my tests for some previous versions. esp-modbus got a lot of updates and they apply to overall functionality. I will try to reproduce ASAP and then will fix this accordingly. The issue will follow the formal process and I will inform you about the status.

   Alex please correct me if i'm wrong here! This case happens as the socket gets closed and is not opened again (same can be seen in static IP logs).

   There is some aspect of handling that needs to be verified. I need to check this and fix a bit later.

   If it is possible, please consider to send the reproducible example and the sdkconfig file.

   Thanks.

   👍React with 👍1Reacted by Ram
4. alisitsyn

   self-assigned this

   on Apr 10, 2026
5. alisitsyn commented on Apr 16, 2026

   

   alisitsyn

   on Apr 16, 2026

   Last edited by alisitsyn

   Collaborator

   More actions

   Hi @ram-bt ,

   I just checked the scenario you provided above. As per my results when the Ethernet cable reconnected the Modbus master still be able to repair the connection and restart polling. My experiments are preformed on two ESP32-Ethernet-Kit_A_V1.2 (master + slave) connected to Modbus segment over Ethernet connection. The code is from latest main branch of the project.

   The log of master is attached:
   esp32_eth_modbus_communication.log
   In the log I comment all the stages like below:
   "<<<<<<<<<<<< Connected to Modbus stale successfully, start polling"

   According to my test the Modbus master can re-establish communication with slave after cable re-connection.
   I use the default ethernet configuration in the kconfig:

   

   I think this issue requires more information about your project and some details of the configuration.

   1. Please make sure you set static IP address in the master descriptor table.

   char *slave_ip_address_table[MB_DEVICE_COUNT + 1] = {
       "01;192.168.0.69;1502",
       NULL              // End of table condition (must be included)
   }
   

   2. Let me know which ethernet boards you use and how they configured.
   3. Please provide your sdkconfig file.
   4. Check and give some information related to your Modbus segment environment.

   Thanks.

   👍React with 👍1Reacted by Ram
6. ram-bt commented on Apr 16, 2026

   

   ram-bt

   on Apr 16, 2026

   Last edited by ram-bt

   Author

   More actions

   Hi Alex, Sorry for the delay. I'm facing the same issue as #161 and after using the component from bugfix/improve_event_handling_path_timing i'm having some problems which i will mention under #162 .

   Let me send you a reproducible example in a bit. I will share my sdkconfig here.

   #
   # Modbus configuration
   #
   CONFIG_FMB_COMM_MODE_TCP_EN=y
   CONFIG_FMB_TCP_PORT_DEFAULT=502
   CONFIG_FMB_TCP_PORT_MAX_CONN=5
   CONFIG_FMB_TCP_CONNECTION_TOUT_SEC=2
   CONFIG_FMB_TCP_KEEP_ALIVE_TOUT_SEC=4
   # CONFIG_FMB_TCP_UID_ENABLED is not set
   CONFIG_FMB_COMM_MODE_RTU_EN=y
   CONFIG_FMB_COMM_MODE_ASCII_EN=y
   CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND=10000
   CONFIG_FMB_MASTER_DELAY_MS_CONVERT=200
   CONFIG_FMB_QUEUE_LENGTH=50
   CONFIG_FMB_PORT_TASK_STACK_SIZE=4096
   CONFIG_FMB_BUFFER_SIZE=260
   CONFIG_FMB_SERIAL_ASCII_BITS_PER_SYMB=8
   CONFIG_FMB_SERIAL_ASCII_TIMEOUT_RESPOND_MS=1000
   CONFIG_FMB_PORT_TASK_PRIO=10
   # CONFIG_FMB_PORT_TASK_AFFINITY_NO_AFFINITY is not set
   CONFIG_FMB_PORT_TASK_AFFINITY_CPU0=y
   # CONFIG_FMB_PORT_TASK_AFFINITY_CPU1 is not set
   CONFIG_FMB_PORT_TASK_AFFINITY=0x0
   CONFIG_FMB_CONTROLLER_SLAVE_ID_SUPPORT=y
   CONFIG_FMB_CONTROLLER_SLAVE_ID=0x00112233
   CONFIG_FMB_CONTROLLER_SLAVE_ID_MAX_SIZE=32
   CONFIG_FMB_CONTROLLER_NOTIFY_TIMEOUT=20
   CONFIG_FMB_CONTROLLER_NOTIFY_QUEUE_SIZE=20
   CONFIG_FMB_CONTROLLER_STACK_SIZE=4096
   CONFIG_FMB_EVENT_QUEUE_TIMEOUT=20
   # CONFIG_FMB_TIMER_USE_ISR_DISPATCH_METHOD is not set
   # CONFIG_FMB_EXT_TYPE_SUPPORT is not set
   CONFIG_FMB_FUNC_HANDLERS_MAX=16
   # CONFIG_FMB_COMPILER_STATIC_ANALYZER_ENABLE is not set
   CONFIG_FMB_MDNS_INTEGRATION_ENABLE=y
   # end of Modbus configuration
   # end of Component config
   

   ---

   1. Please make sure you set static IP address in the master descriptor table.
      =>

   char *slave_ip_addr_table[] = {
       "01;192.168.4.113;1502",
       NULL,
   };
   

   2. Let me know which ethernet boards you use and how they configured.
      => I am using LAN8720A-CP for PHY and using MAC of ESP32 (What more details should i provide here?)
   3. Please provide your sdkconfig file.
      => sdkconfig.zip
   4. Check and give some information related to your Modbus segment environment.
      => I have a simple setup where MB TCP Slave & Master share the same network. I have set 192.168.4.113 as static IP for the slave. I have 2 I/O [14,15] set as input on slave and master polls this slave every 5 seconds. My main priority is (considering stable network) communication between Master and Slave. (What more details should i provide here?)
7. ram-bt commented on Apr 16, 2026

   

   ram-bt

   on Apr 16, 2026

   Author

   More actions

   I will pull the component from main and verify the same once.
8. alisitsyn commented on Apr 16, 2026

   

   alisitsyn

   on Apr 16, 2026

   Last edited by alisitsyn

   Collaborator

   More actions

   Hi @ram-bt,

   Thanks for update. Before continue with this and providing the concrete recommendations could you try the following settings:

   1. Please try to set the CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND=3000, check the mbm_opts->comm_opts.tcp_opts.response_tout_ms = 3000 (overrides the value from define above),
   2. FMB_TCP_KEEP_ALIVE_TOUT_SEC=2000,

   Recompile and restart your tests.
   It seems in your tests you get other race condition related to the issue, the fix is in progress but is not merged. Please try to not exceed the CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND=3000!

   👍React with 👍1Reacted by Ram
9. ram-bt commented on Apr 16, 2026

   

   ram-bt

   on Apr 16, 2026

   Author

   More actions

   Thanks for the quick response alex.

   1. Please try to set the `CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND=3000`, check the  `mbm_opts->comm_opts.tcp_opts.response_tout_ms = 3000` (overrides the value from define above),
   

   I have kept this field empty so that it takes the default value, and instead i try to use the queues waittime to poll after 5 seconds (let me share the example real quick for you to see)

   I have also modified TCP keep alive (FMB_TCP_KEEP_ALIVE_TOUT_SEC) to 2 sec

   But i still notice the same issue:

   I (310665) MB_TCP: [ETH]- Link Down
   W (310675) mb_port.tcp.master: 0x3ffd85a8, node #0, socket(#57)(192.168.4.113), error handling.
   E (310675) mb_port.tcp.master: Node: 0, try to repair lost connection, err= -11
   E (310685) port.utils: Socket(#-1)(192.168.4.113), fcntl() call error=9    << === //why is this happening?
   E (310685) mb_port.tcp.master: Modbus connection phase, slave: 0 (192.168.4.113), connection error (-11).
   I (312665) Connection Handler: ETH HW Addr 24:XX:C3:XX:23:XX
   E (313665) MB_CONTROLLER_MASTER: mbc_master_get_parameter(131): Master get parameter failure, error=(0x103) (ESP_ERR_INVALID_STATE).
   I (313665) esp_netif_handlers: eth ip: 192.168.4.187, mask: 255.255.255.0, gw: 192.168.4.1
   I (313675) MB_TCP: Got IP
   W (313675) mbc_tcp.master: 0x3ffafb98 Try to send request for cid #0 with uid = 1, node is disconnected.
   
10. alisitsyn commented on Apr 16, 2026

    

    alisitsyn

    on Apr 16, 2026

    Last edited by alisitsyn

    Collaborator

    More actions

    @ram-bt ,

    E (310685) port.utils: Socket(#-1)(192.168.4.113), fcntl() call error=9

    The error says "Bad file descriptor" because the connection was closed in the error handler then we try to resolve the node address and reconnect. The E (310685) mb_port.tcp.master: Modbus connection phase, slave: 0 (192.168.4.113), connection error (-11). says that the stack tries to connect to the slave node but for some reason can not do this because socket API returns the connection error. This is why the node is kept disconnected W (313675) mbc_tcp.master: 0x3ffafb98 Try to send request for cid #0 with uid = 1, node is disconnected. and the master reports about it and timed out transaction E (313665) MB_CONTROLLER_MASTER: mbc_master_get_parameter(131): Master get parameter failure, error=(0x103) (ESP_ERR_INVALID_STATE). From the stack handling standpoint everything works just as expected but the master can not reconnect to the slave. This is network issue and also its event queue specific aspect. This is expected behavior of master when it gets the connection error and it does not try to reconnect immediately, can do this only after timeout.

    Please send me more log. This looks strange.

    👍React with 👍1Reacted by Ram
11. ram-bt commented on Apr 16, 2026

    

    ram-bt

    on Apr 16, 2026

    Author

    More actions

    Sure Alex. Will do

    👀React with 👀1Reacted by Alex Lisitsyn
12. alisitsyn commented on Apr 16, 2026

    

    alisitsyn

    on Apr 16, 2026

    Collaborator

    More actions

    @ram-bt,

    I need to inform that from tomorrow I will not be able to respond at least one week. I will return to it ASAP. Please keep me posted if you have updates. I will check the results when possible.
    Thank you for understanding.

    👍React with 👍1Reacted by Ram
13. ram-bt commented on Apr 16, 2026

    

    ram-bt

    on Apr 16, 2026

    Author

    More actions

    I need to inform that from tomorrow I will not be able to respond at least one week. I will return to it ASAP. Please keep me posted if you have updates. I will check the results when possible. Thank you for understanding.

    No worries. I will share updates here.

    👍React with 👍1Reacted by Alex Lisitsyn
14. espressif-bot

    added

    Status: In Progress

    and removed

    Status: Opened

    on May 12, 2026
15. 8 remaining items

    Load more

16. ram-bt commented on May 20, 2026

    

    ram-bt

    on May 20, 2026

    Author

    More actions

    Thank you for your attention and detailed information. I was able to start your project normally with esp_eth_phy_new_ip101() ( IP101 hw that is what I have now). I will try to reproduce and investigate the issue. Hope it is possible with IP101. I will let you know once possible.

    Alex, I have a ETH kit(it is a lil older [V1.1 WROVER-B]) and the same issue can be reproduced on it from my end

    👍React with 👍1Reacted by Alex Lisitsyn
17. ram-bt commented on May 20, 2026

    

    ram-bt

    on May 20, 2026

    Author

    More actions

    Let me know if i should share any logs/build for the same

    👍React with 👍1Reacted by Alex Lisitsyn
18. alisitsyn commented on May 20, 2026

    

    alisitsyn

    on May 20, 2026

    Last edited by alisitsyn

    Collaborator

    More actions

    Alex, I have a ETH kit(it is a lil older [V1.1 WROVER-B]) and the same issue can be reproduced on it from my end

    Yes, I can reproduce this partially at least and have some findings. I am looking to the ways for correct fix for the issue.

    👍React with 👍1Reacted by Ram
19. alisitsyn

    added the

    Bug

    issue type on May 21, 2026
20. alisitsyn

    added this to the v2.1.3 milestone on May 21, 2026
21. alisitsyn commented on May 21, 2026

    

    alisitsyn

    on May 21, 2026

    Collaborator

    More actions

    @ram-bt ,

    Current simple way to fix the issue is in PR #173. There are others (in progress) and PR will be updated.

    👍React with 👍1Reacted by Ram

    ❤️React with ❤️1Reacted by Ram
22. ram-bt commented on May 21, 2026

    

    ram-bt

    on May 21, 2026

    Author

    More actions

    Current simple way to fix the issue is in PR #173. There are others (in progress) and PR will be updated.

    Alex, appreciate the quick fix! I will test at my end and get back to you

    👍React with 👍1Reacted by Alex Lisitsyn

    👀React with 👀1Reacted by Alex Lisitsyn
23. alisitsyn commented on May 25, 2026

    

    alisitsyn

    on May 25, 2026

    Collaborator

    More actions

    @ram-bt ,

    Just a reminder: Please check this when possible. This should fix your issue.

    Thanks.

    👍React with 👍1Reacted by Ram
24. alisitsyn commented on Jul 2, 2026

    

    alisitsyn

    on Jul 2, 2026

    Collaborator

    More actions

    Merged to main with commit: c1a4193
25. alisitsyn

    closed this as completedon Jul 2, 2026
26. espressif-bot

    added

    Status: Reviewing

    Status: Resolved

    Resolution: Done

    and removed

    Status: In Progress

    Status: Reviewing

    on Aug 3, 2026