|
From: | address@hidden |
Subject: | Re: [lwip-users] TCP retransmission |
Date: | Wed, 22 Nov 2017 17:00:14 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
Nikolas Karakotas wrote:
True for not providing enough information. Deducing wireshark information I can say: 1. Remote host send a Modbus request 2. For whichever reason we don't respond to it as it may have been lost because of network or Ethernet driver 3. The remote host then re sends the request and we are able to receive it notifying with a Dup Ack 4. The remote host then sends the re-transmission of the previous packets lost with 24 bytes ( contains 2 modbus requests now) 5. It's forwarded to the application layer but I found out that the application layer Modbus implementation doesn't handle fragmented Modbus requests well
Please, more info! I can only assume that lwIP is the Modbus-TCP server having the IP address 10.200.61.1 and 10.200.221.100 is some non-lwIP Modbus-TCP client. In that case, it seems like the Modbus-TCP client retransmits 2 requests in one TCP segment (note that frame 2 and 3 have a TCP length of 12 while frame 5 has 24). This is perfectly valid for TCP. It seems like your application cannot handle 2 requests coming in with one "recv" callback.
This is a common error people do when programming TCP applications: you get a stream, not packets. You need to handle the depacketization at application level.
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |