Re: [lwip-users] Re: Re: Re: TCP duplicate ACK

[David Empson]

> Yes, you are right, 192.192.192.39 is PC's IP, and the other is my
> board's.  I just have a test connecting PC and my board using a wire,
> so the IP address is temporary. I think it does't infulence the test
> result.

No, that configuration is fine. I just wanted to check that you weren't 
intending to use that address in a real world situation or were trying to 
use it while hooked up to a network which could be routed through to the 
Internet.

> I use the modbus/TCP port from
> FreeModbus(http://freemodbus.berlios.de/), just a litte change from
> its lwip/MCF5235 port, lwip port from
> FreeRTOSV5.1.1(Unsupported_Demos/STR9_lwIP_1_3_0_GCC_SO) and also the
> FreeRTOSV5.1.1 RTOS. My board includes a lpc2214 and a enc29j60 b7 net
> chip from microchip, net driver is changed from u-boot-2008-10 and
> microchip tcp/ip stack. The file is a zip file of the netif driver,
> but some comments in the file is written in Chinese not English, I
> don't know if this can help.
>
> I have checked modbus/TCP port and found that it use the raw api, but
> run in a separate task from the tcpip thread, I don't know if this is
> right. The netif ethernetif_input is also a separate task. In the
> lwipopt.h file, I #define LWIP_NETCONN  1 and #define LWIP_RAW    1.

Multiple tasks using LWIP could account for some of the problems you are 
seeing. The LWIP core must only be used from a single task at any time, but 
mailboxes or similar mechanisms can be used to pass data between tasks. It 
sounds like most of the pieces you are using are existing code which should 
be working properly, assuming it was all updated for compatibilty with LWIP 
1.3.0. The driver is the piece most likely to have problems, since it was 
modified from one used with a different TCP/IP stack.

I may not be able to help much further with the specific details of how LWIP 
is being used in your system, but I hope my initial comments and the details 
you provided have narrowed down the problem, and may be enough for other 
people to suggest areas to look, or ways to extract more information. For 
example, you might be able to turn on some debugging output from LWIP.

There are three separate issues in your previous data capture:

1. Unexpected duplicate Acks. Not a serious problem, but this might be a 
symptom of something else and I would like to find out if this is known 
behavoiur of LWIP or if there is an obvious explanation for it.

2. Duplication of the Modbus/TCP response. This is happening at or above the 
TCP layer, so the driver isn't directly responsible (e.g. it is not sending 
a duplicate frame). It could still be caused by a bug in your driver, such 
as not correctly handling data after it has been transmitted (resulting in 
corruption of pbufs or LWIP's transmit queues), or threading issues 
involving your driver (resulting in two threads executing code in LWIP at 
the same time, causing data corruption). It seems more like a higher level 
problem, such as an application bug.

3. FIN being sent unexpectedly early. I don't know offhand if LWIP can do 
this by itself, or whether it could only happen as a result of application 
code calling tcp_close(). This one may be easier to track down.

> Forgive my poor English.

Seems pretty good to me.