[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] serious lwIP 1.4.0 error
From: |
Valery Ushakov |
Subject: |
Re: [lwip-users] serious lwIP 1.4.0 error |
Date: |
Wed, 3 Apr 2013 16:41:25 +0000 (UTC) |
User-agent: |
tin/2.0.1-20111224 ("Achenvoir") (UNIX) (NetBSD/6.1_RC1 (macppc)) |
Peter Sprenger <address@hidden> wrote:
>> Peter Sprenger <address@hidden> 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