Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
So, I found the problem on my end: The initialization code was called twice... The first time when NETIF was UP, the second time when DHCP got an IP-address... (And the initialization the second time obviously was badly written and screwed up the list of lpcbs) I guess this behaved differently in 1.3.2, as in 2.0.2 there was a split between link and netif. Sorry to have bothered you with such a rookie mistake... (Now I have still problem with reset packages for the n+1 connections... But this time I will debug more before posting...) On 4 August 2017 at 11:55, Tony wrote: > > > _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 wrote: > >> One more observation from a debugging session (with n=2) with these >> settings >> >> #define MEMP_NUM_TCP_PCB2 >> #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 lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
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 wrote: > One more observation from a debugging session (with n=2) with these > settings > > #define MEMP_NUM_TCP_PCB2 > #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 lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
One more observation from a debugging session (with n=2) with these settings #define MEMP_NUM_TCP_PCB2 #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 lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
On 3 August 2017 at 21:16, goldsi...@gmx.de wrote: > Tony wrote: > >> The aim is to only allow n open TCP connection at a time, and reject all >> further connection requests. This worked reasonably well in 1.3.2, but now >> fails in 2.0.2. >> [..] >> HOWEVER: this n+1 connection terminates the very 1st connection (takes >> over the 1st PCB?). >> > > Although it's strange it's like that, this is expected behaviour of > tcp_alloc(). I compared 2.0.2 to 1.3.2 and I don't really see a difference > though... > Anyway, the pcb limitation might not be the correct solution. A listen > backlog might better do what you want. > If you want to stay with your pcb limitation, try calling > "tcp_setprio(newpcb, TCP_PRIO_MAX);" after you allocate the first n pcbs. > That should prevent tcp_alloc from reusing them. > Good! This fixes the "n+1 behavior"! For testing I removed the call to tcp_kill_prio(prio); from tcp_alloc(), which should have the same effect (if I am not mistaken). And this seems to do the trick. I need to find the correct position for setting the priority without breaking anything... (I had already removed the tcp_kill_prio(prio) call in 1.3.2 if I am not mistaken, and there was some bug in our app or LWIP which caused the app to crash when LWIP send the reset packages for the n+1 connection - I failed to try it 2.0.2. as well, my bad) However for one time I still managed to hit the "n+2 behavior"... (more below about n+2 below) > > >> Now, if I leave all previous connections open and make a n+1 connection >> (the 6th connection in this example) I hit an exception (the processor >> tries to access memory that does not exists and I hit the exception handler >> in the MCU). >> > > I narrowed down the origin of the fatal exception in tcp_alloc() to the >> code following this comment: >> /* zero out the whole pcb, so there is no need to initialize members to >> zero */ >> >> The problem at that point seems to be that a struct tcp_pcb_listen (that >> is still in use) is reused and overwritten as a struct tcp_pcb... >> > > Ehrm, the pcb that is used there should *NOT* be a listen pcb. It comes > from the MEMP_TCP_PCB pool, so it's a standard pcb. Why do you think it's a > listen pcb which is still in use? This lets me think you have a port > problem... > I simplified a bit too much the n+2 problem ... my apologies. This is what happens: tcp_alloc() initializes an existing struct tcp_pcb_listen (which is in use) for use as a struct tcp_pcb. tcp_alloc() finishes without problems. But once tcp_input() accesses this pcb (as a listen pcb), the values the pcb used to have are all whacked (the specific problem is the next pointer, which now points to 0x04000400 if I am not mistaken). The exception happens when tcp_input iterates over the listen pcbs after the comment: /* Finally, if we still did not get a match, we check all PCBs that are LISTENing for incoming connections. */ (It is actually the initializing of the "rcv_wnd" in the "normal pcb" in tcp_alloc() that overwrites the next pointer in the "listen pcb" - which seems strange, as they should not line up... I suspect there are more things going on, which I don't grasp...) The function tcp_input() was clearly not properly informed that one listen pcb had been recycled. (Is there a reference counter for PCBs? Or how is this handled?) Unfortunately I lack insight into LWIP (and at the moment into our own application code in that area) to pinpoint where the fault lies. I will investigate further! I found some weirdness in our application which I need to fix first. Kindest regards, Tony ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
Tony wrote: The aim is to only allow n open TCP connection at a time, and reject all further connection requests. This worked reasonably well in 1.3.2, but now fails in 2.0.2. [..] HOWEVER: this n+1 connection terminates the very 1st connection (takes over the 1st PCB?). Although it's strange it's like that, this is expected behaviour of tcp_alloc(). I compared 2.0.2 to 1.3.2 and I don't really see a difference though... Anyway, the pcb limitation might not be the correct solution. A listen backlog might better do what you want. If you want to stay with your pcb limitation, try calling "tcp_setprio(newpcb, TCP_PRIO_MAX);" after you allocate the first n pcbs. That should prevent tcp_alloc from reusing them. Now, if I leave all previous connections open and make a n+1 connection (the 6th connection in this example) I hit an exception (the processor tries to access memory that does not exists and I hit the exception handler in the MCU). Now this indeed looks like a bug in your port, not in lwIP. I narrowed down the origin of the fatal exception in tcp_alloc() to the code following this comment: /* zero out the whole pcb, so there is no need to initialize members to zero */ The problem at that point seems to be that a struct tcp_pcb_listen (that is still in use) is reused and overwritten as a struct tcp_pcb... Ehrm, the pcb that is used there should *NOT* be a listen pcb. It comes from the MEMP_TCP_PCB pool, so it's a standard pcb. Why do you think it's a listen pcb which is still in use? This lets me think you have a port problem... Is there a way to simply "tell" LWIP to "refuse" further connections? As I wrote above, give your other connections a higher prio so new connections won't kill the existing ones. Are there things that I might have missed that need to be changed in my application, when going from 1.3.2 to 2.0.2? None that I know of. If you find any, please let us know! Cheers, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Limiting the number of connections: Possible bug with MEMP_NUM_TCP_PCB?
Hello, I am trying to fix a strange behavior I have with LWIP... Quite possibly I am using the LWIP wrongly, but I am not sure. I took over the maintaining of a embedded project which includes LWIP, and unfortunately I have some problems with networking (and I now face a steep learning curve, as LWIP has been integrated by someone else, and I know not enough about networking...). I updated from 1.3.2 (which was used before) to 2.0.2. This helped with one problem I had - but introduced another. Our application offers one port for SCPI connections. The aim is to only allow n open TCP connection at a time, and reject all further connection requests. This worked reasonably well in 1.3.2, but now fails in 2.0.2. I set the maximum number "n" of TCP PCBs like this, e.g. 4: #define MEMP_NUM_TCP_PCB 4 The problematic behavior is this: The first n connections work fine (in this example 1 to 4), and can be used simultaneously (I leave all 4 connections open). The n+1 connection itself works fine (5th connection in this example), HOWEVER: this n+1 connection terminates the very 1st connection (takes over the 1st PCB?). Now, if I leave all previous connections open and make a n+1 connection (the 6th connection in this example) I hit an exception (the processor tries to access memory that does not exists and I hit the exception handler in the MCU). I narrowed down the origin of the fatal exception in tcp_alloc() to the code following this comment: /* zero out the whole pcb, so there is no need to initialize members to zero */ The problem at that point seems to be that a struct tcp_pcb_listen (that is still in use) is reused and overwritten as a struct tcp_pcb... However, as I have written above, something else goes wrong before that, when the n+1 connection is made. (possibly in tcp_alloc(), when tcp_kill_prio(prio); is called?) Is there a way to simply "tell" LWIP to "refuse" further connections? Are there things that I might have missed that need to be changed in my application, when going from 1.3.2 to 2.0.2? And I would be most grateful for any further hints, e.g. about things I might have missed, typical errors when using LWIP, pointers to tutorials to use, and so on! Kindest regards, Tony ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
