limited tcp connections

[cagdassengel1983]

Hi Alejandro,

I am testing your Modbus TCP server. When I disconnect and connect the ethernet cable 5 times, modbus poll client can not reconnect to the server. When I increase MEMP_NUM_TCP_PCB macro from 5 to 10 in lwip opt.h, the client can not reconnect to the server after 10 times ethernet cable disconnection.

The definition of MEMP_NUM_TCP_PCB macro is the number of simultaneously active TCP connections. Although ethernet cable is disconnected, lwip doesn't seem to decrease active TCP connection count. Is this related with your library? Is there a bug about this issue?

Best Regards,

Cagdas Sengel

[cagdassengel1983]

Hi,

In addition, icmp ping works after 5 disconnections.

Best Regards,

Cagdas

[alejoseb]

Hi, the library implements an aging algorithm, if the cable is disconnected it will take some time till the resources are recycled and new connections are allowed. So after a while, you may be able to connect again. You can adjust the aging parameters in the library header file. If the aging algorithm is not working, it could be a bug.

[cagdassengel1983]

Hi Alejandro,

Today, I again tested your Modbus TCP Slave implementation in debug mode. ModbusCloseConnNull(modH) function is called after I disconnect the ethernet cable (i.e after 2-3 seconds). This function calls netconn_close and netconn_delete functions. However, the problem is still ongoing. MEMP_NUM_TCP_PCB macro limits the maximum connection limit. After 5th disconnection, modbus tcp server (modbus pool) can not connect to the STM32 Modbus TCP Slave.

if (recv_err == ERR_TIMEOUT) //No new data { //continue the aging process modH->newconns[modH->newconnIndex].aging++;

  // if the connection is old enough and inactive close and clean it up
  if (modH->newconns[modH->newconnIndex].aging >= TCPAGINGCYCLES)
  {
      //ModbusCloseConn(clientconn->conn);
      ModbusCloseConnNull(modH);
      clientconn->aging = 0;
  }

  return xTCPvalid;

}

Is this a bug related to lwip? Can you try it in your setup?

Best Regards,

Cagdas

[cagdassengel1983]

Hi Alejandro,

I decreased TCP_TMR_INTERVAL macro in tcp_priv.h from 250 to 3, and the problem is gone.

Best Regards,

Cagdas

[alejoseb]

Hi, thanks for diving deep in this issue.

I think the right place to define that macro is the lwipopts.h file, or maybe the macro is an option to configure in the STM32CubeIDE already. It is better to define the macro in the right place, otherwise the macro could be changed again when lwip is updated

[ttelik]

Perhaps someone can shed a little further insight into what's happening here. Surely, reducing the timebase by almost 100x will speed up the disconnect, but why doesn't reducing the TCPAGINGCYCLES variable work? What else is affected by reducing TCP_TMR_INTERVAL quite so much?