Trying to use MEMP_NUM_TCP_PCB +1 TCP connections terminates existing TCP connection

[habazut]

Describe the bug

The LwIP implementation has a compiled in maximum number of TCP connections (MEMP_NUM_TCP_PCB) that can be active simultaniously. By default this seems to be 10. If now the 11th TCP connection is opened then the library does not reject connection number 11 but instead terminates one of the 10 existing active connections.

To Reproduce

Write a small program that accepts N TCP connections echoing characters and connect with for example telnet. Look at the behaviour when connection 11 is connected.

Expected behavior

Connection 11 is rejected.

Versions

Resolving Nucleo-F429ZI dependencies...
Platform ststm32 @ 17.6.0 (required: ststm32 @ 17.6.0)
├── framework-arduinoststm32 @ 4.20801.240815 (required: platformio/framework-arduinoststm32 @ ~4.20801.0)
├── framework-cmsis @ 2.50900.0 (required: platformio/framework-cmsis @ ~2.50900.0)
├── tool-dfuutil @ 1.11.0 (required: platformio/tool-dfuutil @ ~1.11.0)
├── tool-dfuutil-arduino @ 1.11.0 (required: platformio/tool-dfuutil-arduino @ ~1.11.0)
├── tool-openocd @ 3.1200.0 (required: platformio/tool-openocd @ ~3.1200.0)
├── tool-stm32duino @ 1.0.1 (required: platformio/tool-stm32duino @ ~1.0.1)
└── toolchain-gccarmnoneeabi @ 1.120301.0 (required: platformio/toolchain-gccarmnoneeabi @ ~1.120301.0)

Libraries
├── STM32Ethernet @ 1.4.0 (required: stm32duino/STM32Ethernet @ ^1.4.0)
└── STM32duino LwIP @ 2.1.3 (required: stm32duino/STM32duino LwIP @ ^2.1.3)

$ pio --version
PlatformIO Core, version 6.1.6

Hardware (please complete the following information):
Nucleo-F429ZI

Additional context

I have not succeeded to turn on the LwIP builtin debugging ... none of the descriptions I did find on the net did actually result in any output to serial, sorry.

The DCCEX project uses this here:
(URL to current code which uses LwIP)
https://github.com/DCC-EX/CommandStation-EX/tree/6b0dc272ea8f8191ba7e3fd20c1f835b975bb699
It's not a small project and one needs first to turn on ethernet support so it listens to TCP on port 2560

Regards,
Harald

[fpistm]

Hi @habazut
This library is only a porting of the the LwIP stack modified by ST: stm32_mw_lwip version v2.1.3_230818.

No change made here. What you describe is that the connection is limited to 10 and it seems the behavior is respected.

Definition done here:
https://github.com/stm32duino/STM32Ethernet/blob/cc8310f100c564a587669ba17d56483926780cf0/src/lwipopts_default.h#L54-L56

[habazut]

Let us assume that we have an application wants to choose between connections. For example only transfer data to some specific IP addresses or after some specifc login procedure. The current behavour of the library makes it impossible to provide that service in a reliable way as anyone who can reach the IP number of the STM32 can easily launch a Denial of Service attack. An attacker can take down any active connection just by opening new connections (and opening 10 connections is not that big of a hurldle). In that way the application will never even get to the point where it can decide to keep or deny the TCP connection as all the connections are reaped before it even has the chance to do so. In the default this number is 10, but it does not matter if the number is increased to 20, 50 or 100 as the reaping takes place at N+1.

You have not commented the LwIP debugging issue either. Can I assume that you do not care about that as you seem no to care about the DoS issue?

I may know a workaround from my application which I think hinders the DoS described above. Do you want to know about that?

Regards,
Harald.

[fpistm]

Hi @habazut

Can I assume that you do not care about that as you seem no to care about the DoS issue?

Never told that. Simply this library is simply a port of the stm32_mw_lwip as an Arduino Library no change made here. So if you think there is an issue, you should report it to this repo as I guess it is also present here. Then when fixed in the repo we will benefit it here.

I may know a workaround from my application which I think hinders the DoS described above. Do you want to know about that?

Of course, this is a community project so every contribution/feedback are welcome.

About the debug I have to check.

[fpistm]

To enable the debug in the opt file add for example:

#define LWIP_DEBUG              LWIP_DBG_ON
#define NETIF_DEBUG             LWIP_DBG_ON
#define DHCP_DEBUG              LWIP_DBG_ON
#define UDP_DEBUG               LWIP_DBG_ON
#define MEMP_DEBUG              LWIP_DBG_ON
#define MEM_DEBUG               LWIP_DBG_ON
#define ICMP_DEBUG              LWIP_DBG_ON

All possible value are referenced here:
https://www.nongnu.org/lwip/2_0_x/group__lwip__opts__debugmsg.html

Result example:

pbuf->len = 548
pbuf->tot_len = 548
skipping option 28 in options
searching DHCP_OPTION_MESSAGE_TYPE
DHCP_OFFER received in DHCP_STATE_SELECTING state
dhcp_handle_offer(netif=0x2000a9bc) st0
dhcp_handle_offer(): server 0xfe01a8c0
dhcp_handle_offer(): offer for 0x7801a8c0
dhcp_select(netif=0x2000a9bc) st0
transaction id xid(4bb5f646)
udp_send: added header in given pbuf 0x20000660
udp_send: sending datagram of length 316
udp_send: UDP packet length 316
udp_send: UDP checksum 0x0000
udp_send: ip_output_if (,,,,0x11,)
dhcp_select: REQUESTING
dhcp_select(): set request timeout 2000 msecs
dhcp_fine_tmr(): request timeout
dhcp_timeout()
dhcp_timeout(): REQUESTING, DHCP request timed out
dhcp_select(netif=0x2000a9bc) st0
transaction id xid(4bb5f646)
udp_send: added header in given pbuf 0x20000660
udp_send: sending datagram of length 316