On Tue, 2006-11-28 at 08:53 -0500, Tom Hennen wrote: > I think I understand you're reasoning, after a fashion. > > It does seem to be a problem for me because I'm queuing the pbufs in > my link layer driver (using pbuf_queue). As a result the length of > the pbuf chain reported by pbuf_clen is not what tcp_in expects it to > be and so pcb->snd_queuelen ends up wrapping around from 0 to ~255 > whenever pbuf_clen(next->p) > pcb->snd_queuelen.
That packets that you pass in to lwIP from the link layer should have no direct effect on snd_queuelen, so how you construct them should be of no consequence. When an ACK is passed in from your link layer snd_queuelen is decremented by the number of pbufs in ***the packet that is acknowledged***, not the number of pbufs in the packet that you've just passed in that does the acknowledging. snd_queuelen was earlier (in tcp_out.c:tcp_enqueue()) incremented by the number of pbufs in the same packet (when it was enqueued on the unacknowledged or unsent list) so there is something really wrong if you've ended up with snd_queuelen < the number of pbufs in one of the packets in those queues. We should probably be asserting this in tcp_in.c:tcp_receive(). For this to happen, my guess is your packet queues are getting corrupted, most likely due to insufficient locking and protection of the stack resulting in two threads accessing it at the same time. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
