On 6 Mar 2011, at 22:07, Bernard Mentink wrote: > I am trying to debug a tcp error I have with lwip, I have attached a log of > the errors created when > I turn on the TCP_RST_DEBUG debug zone. > > These errors occur when serving up a web page ( the 1st few seconds of > loading the page seem fine in Wireshark, but then I get these reset errors ..)
This makes a lot of sense given your earlier trace. lwIP think it has closed a connection that was passively opened on port 80 and the state for that connection has been removed, so the packets received for that connection go to the other connection on port 80: this listening socket. Those packets are completely wrong for a listening socket (it's complaining about the ACK flag being set, but there's more wrong than that) and so it sends another reset. This repeats. What's not clear is why the connection was first closed, and why the other end continues to send packets after the connection is reset. I wonder if perhaps neither of these is true. If instead of closing the connection the list of active pcbs was corrupted, this would mean that received packets would be routed to the listening socket as we see above, and result in the reset. If this happened frequently on different connections we might see the pattern you've reported. Corrupted pcb lists is a common symptom of two threads being active in the lwIP stack at the same time. I would give a lot of attention to threading, and how it is handled in your application. Note that this includes the driver clashing with the rest of the stack when it passes up a received packet; it should be calling netif->input() (and this should probably be set to tcpip_input() when you create the net if, although that depends on your configuration and API use, and I can't remember your details off the top of my head). Hope that helps, Kieran _______________________________________________ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users