Re:tcp_connect() trying to insert pcb into tcp_active_pcbs(it's already there!)
I've seen this behavior and been researching it these days.
I implemented a function on client to reset a established or in-connecting-mode TCP connection. It calls tcp_abort(), then waits for a while (100 ms), and then trys to connect the server port again.
Sometimes it works well. The connection can be establied again if the server is available on the network. But sometimes I found the previous PCB hadn't been purged clearly: it was still on the tcp_active_pcbs list and tcp_tmr() got locked as "p==p->next".
Another specific case of mine is there's another TCP connection on the client with a telnet server. I want to keep this connection while resetting the other one. I found in "tcp_input", current using PCB would be moved to the front of the tcp_active_pcbs list. I wonder whether it the problem is.
>I've been using LWIP for a while now (a port to the TI'6711) and have
>been bumping into an odd problem where the TCP_REG() macro is trying to
>stuff a pcb onto the tcp_active_pcbs list, but the pcb it's working with
>is already on the list. The list gets corrupted at this point and the
>tcp_tmr() thread gets locked in an infinite loop. The TCP_REG in
>question is in the tcp_connect() call in tcp.c.
>We are using the sockets api, and the test case basically has a client
>thread periodically trying to connect to a server socket on a box that
>isn't on the network.
>I suspect that the problem may ultimately be a client software bug
>(using an invalid socket or not cleaning up properly?), but was
>wondering if anyone out there has seen this behavior? As far as I can
>tell, the only way to get into this mode is if we were trying to connect
>an already in-use socket... bad, but shouldn't result in death-of-a-stack...