Peter Sprenger <[email protected]> wrote: >> Peter Sprenger <[email protected]> wrote: > >>> The lwIP 1.4.0 problem is (I am using raw API), that lwIP gets a >>> [FIN,ACK] from the other side (Firefox), but instead of doing a >>> tcp_sent callback, it resubmits 3 times the packet that was already >>> acked in the [FIN,ACK]. This leads to a hanging half-closed situation. >>> Only after some minutes the Firefox on the PC will close the >>> connection. Do you know if this has been fixed? > >> Stupid question, but are you sure the FIN|ACK datagram actually >> reaches lwIP tcpip thread? You may be out of MEMP_NUM_TCPIP_MSG_INPKT. >> I ran into this a few times with similar symptoms - lwIP would >> retransmit data that looks ACKed if you only check the tcpdump trace. > > I am not sure. Since I use no RTOS "NO_SYS" is defined to "1" and then > the "MEMP_NUM_TCPIP_MSG_INPKT" parameter is not used. What have I to > change then?
Can you verify that no packets were dropped on the path from the network card to the lwIP tcpip thread? MEMP_NUM_TCPIP_MSG_INPKT is just an example of why a packet may be dropped. -uwe _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
