|
From: | Tony |
Subject: | Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB? |
Date: | Fri, 4 Aug 2017 13:08:47 +0200 |
_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:=> This overwrites the "last remaining" listening pcb !!!0xb76c (this was the starting address of first "listening pcb", this "normal pcb will overlap with second lpcb !!!)n+2 gets this pcb=> Now we have "lost" the lpcb 0xb76c !!!n+1 (third connection in this example) gets this pcbThe first two connections use the following pcbs:One more observation from a debugging session (with n=2) with these settings
#define MEMP_NUM_TCP_PCB2
#define MEMP_NUM_TCP_PCB_LISTEN2 (Hex numbers are addresses of pcbs or lpcbs)Two listening lpcb initially:
0xb78c
0xb76c
0xbab4 (pcb first connection)
0xba18 (pcb second connection)
0xbab4 (reuses pcb from first connection)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?
[Prev in Thread] | Current Thread | [Next in Thread] |