On 3 August 2017 at 21:16, goldsi...@gmx.de <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
