On Sat, Oct 24, 2009 at 12:02 PM, Giovanni Parodi
<giovanniparodi79@xxxxxxxx> wrote:
>
> Good morning everyone,
> I'm a newbye in networking application and I trying to debug a strange
> problem that I have sending through TCP protocol some data from a DSP based
> system to a PC application
> The problem is that that the application running on PC disconnects after few
> packets, and so I used wireshark to debug the problem.
> It seems some packet get lost (I use a cross cable to connect the devices)
> and that the system isn't able to recover from such a problem.
> Furthermore I found out that Acknowledgement number generated by the DSP
> runnign the server appl always equals 1.
> Do you have any idea about some wrong setting that could generate such a
> behaviour?
> Giovanni
>
Hi Giovanni,
10.31.11.31 always sends relative TCP ACK 1 because 10.31.11.219 never
sends any application layer data. 10.31.11.31 is always waiting for
10.31.11.219 to send its first byte of application layer data, but
that never happens. 10.31.11.31 is the system that sends all the data
in your conversation (23,109 bytes).
The incorrect TCP checksum 0x2b52 could be added by the NIC as
indicated by Wireshark's message (TCP Checksum offload?" or it could
be hardcoded by the app on 10.31.11.219. Where did you perform the
capture?
Why do you think "the system isn't able to recover from such a
problem"? I see the missing bytes of data are retransmitted such that
10.31.11.219 ACKs 49281 before 10.31.11.219 tears down the connection
with a RST ACK.
Sincerely,
Richard