Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?

[Tony]

And one more thing:

In our app, when the network starts, the following code is how the listening is initialized. This was working OK in 1.3.2, but I suspect this breaks 2.0.2 and could cause the problems I see now. Is this a correct way to initialize the listening connection, or is this code wrong?

_tcppcb = tcp_new();
...

tcp_bind(_tcppcb, IP_ADDR_ANY, _port);

// tcp deallocates _pcb, see wiki of lwIP
struct tcp_pcb * listen_pcb = tcp_listen(_tcppcb);
...

_tcppcb = listen_pcb;

tcp_accept(_tcppcb, _netsrv_accept_cb);

On 4 August 2017 at 11:43, Tony <address@hidden> wrote:

One more observation from a debugging session (with n=2) with these settings

#define MEMP_NUM_TCP_PCB                2
#define MEMP_NUM_TCP_PCB_LISTEN         2

(Hex numbers are addresses of pcbs or lpcbs)

Two listening lpcb initially:
0xb78c
0xb76c

The first two connections use the following pcbs:
0xbab4    (pcb first connection)
0xba18    (pcb second connection)

n+1 (third connection in this example) gets this pcb
0xbab4    (reuses pcb from first connection)

=> Now we have "lost" the lpcb 0xb76c !!!

n+2 gets this pcb

0xb76c (this was the starting address of first "listening pcb", this "normal pcb will overlap with second lpcb !!!)

=> This overwrites the "last remaining" listening pcb !!!

If I leave MEMP_NUM_TCP_PCB at 2, but increase the MEMP_NUM_TCP_PCB_LISTEN to 6 I get almost identical behavior (different addresses obviously) with the same failure at n+2 connection (one lpcb dropped at n+1, last remaining lpcb overwritten at n+2).

I will not rule out that some LWIP settings (maybe pcb memory allocation settings?) are wrong in my project. Is there any setting I could try?