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 <[email protected]> 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? > > > >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
