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

[David Empson]

"shiyou yu" <address@hidden> wrote:
> I don't if the file can be sent properly, this is the Ethereal capture 
> file.

Yes, it came through OK.

I didn't know Wireshark could read Modbus/TCP. That will be handy if I ever 
need to implement it. (We're doing DNP3 over TCP and serial, or Modbus over 
serial, but our clients haven't needed Modbus/TCP yet.)

In your capture, I assume the station initiating the connection 
(192.192.192.39) is the PC running modbuspoll.

Incidentally, the addresses you are using (192.192.192.x) are valid public 
IP addresses. Are they actually assigned to you? If you were intending to 
use private addresses on a LAN, you should be using addresses in the 
192.168.x.x range (or either of the other two ranges allocated for that 
purpose).

Summary of exchange in your capture:

3. PC > LWIP: SYN
4. LWIP > PC: SYN,ACK
5. PC > LWIP: ACK. (Normal end of the TCP/IP three-way handshake for 
establishing a connection.)
6. PC > LWIP: Modbus/TCP "Read input registers starting at 255, count 4" 
(seq = 1)
7. LWIP > PC: ACK (ack = 1). This ACK didn't actually acknowledge anything 
so it seems to be unnecessary.
8. LWIP > PC: Modbus/TCP response to the request in frame 6. (seq = 1, ack = 
13, so it also acknowledged the data in frame 6).
9. LWIP > PC: ACK (ack = 13). Another unnecessary ACK, this time regarded as 
a duplicate by Wireshark.
10. PC > LWIP: ACK (ack = 18, acknowledges data in frame 8).
11. LWIP > PC: Modbus/TCP response (seq = 18, ack = 13).

Frame 11 appears to be a duplicate copy of the data sent in frame 8, but 
based on the sequence number it is a new message, not a retransmission of 
the previous one. It shouldn't be there, because you've already responded to 
the Modbus/TCP read request. This could be a bug in your application code. 
It is somehow responding twice to the same Modbus request.

The pattern then repeats twice, with the PC sending a request and LWIP 
sending two responses, with two extra superflous ACKs from LWIP each time.

At frame 27, the PC issued another Modbus/TCP read request. LWIP 
acknowledged it but then sent FIN instead of sending a Modbus response, 
indicating that the application on LWIP has closed the TCP connection. There 
are a couple more duplicate acks after that.

The PC application wasn't expecting the connection to have closed and it is 
still expecting a Modbus response, so it sends another Modbus read request, 
and this time LWIP responds with RST indicating that the connection was 
already fully closed and is no longer valid. There is one more duplicate ack 
at the end.


As far as LWIP is concerned, I'm sure anyone else following this thread will 
also want to know which API your application is using to access LWIP (raw, 
netconn or sockets). Your hardware platform and source of the LWIP port and 
network driver might also be relevant.

The only odd behaviour I can see which might be attributed to LWIP is the 
excessive number of acknowledgements, but they aren't causing any problems. 
Everything else might be just something your application code is doing wrong 
in its use of LWIP, or your implementation of the Modbus/TCP protocol.

There could potentially be a resource issue which causes your application or 
LWIP to prematurely close the connection, e.g. running out of pbufs, 
especially if you were expecting to send only one response to each Modbus 
request but are accidentally sending two responses.