1

Doing some basic HTTP transfer from web server to browser. Usually works, but very rarely web assets such as javascript files fail to load. Investigation reveals that during the TCP streaming of data, the Len randomly changes and all hell breaks loose (100% consistent when the problem occurs). I don't know if the Len changing is the issue, but it always precedes the issue. The real issue seems to be straight up loss of data, but my TCP knowledge is too low. I get confused looking between seq/ack/len and figuring out who is acking what, etc. I've attached a screenshot that illustrates the problem and was wondering if anyone could give some insight.

My networking friend says that the browser is the one screwing up here (Firefox) but I don't know..

wireshark capture

If you keep going through this capture, there are about 30 more DUP ACKs, while the web server continues to send the rest of the file with back to normal lens. But the browser doesn't seem to receive the data anymore.

Improve this question

1 Answer 1

Reset to default
1

This has nothing to do with the packet length. Based on the small portion of the packet capture you show there are simply lost packets. The last sequence received was 65793 and then the next packet in the capture starts with 67956. That's why it is repeatedly acknowledging sequence 65793. The server should realize this after a while and resend the missing packets.

Improve this answer
3
  • Thanks. Is this not supposed to be built in to TCP though? I can debug the HTTP server (it's written in C) but is this a socket layer issue? Obviously I doubt there is a bug with TCP, but maybe how this OS (vxworks) implemented something? Commented Nov 19, 2020 at 3:59
  • @pbuzz007: It is is a feature of TCP and is usually implemented in the TCP stack in the OS kernel. The user space server application should not need to worry about this. Note though that the current window is quite large, so at least from the small part you show from the packet capture it is perfectly fine to send more data. But after a while the server side should retransmit the missing packets. It is unclear if this is actually done but it as least note done during the small packet capture you show. Commented Nov 19, 2020 at 4:21
  • Thanks. I hope this is not an OS layer bug, ugh. Commented Nov 19, 2020 at 5:01

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.