-1

This Wireshark issue has been driving my crazy for a few hours. What's happening here?

192.168.2.100 is an Apache server that is serving a static file.

192.168.2.196 is an embedded client downloading the file.

It looks like 192.168.2.196 is happily downloading the file, and then it just starts ignoring 192.168.2.100 and therefore the connection stalls and eventually ends?

Is this correct and why might the client be doing this?

Wireshark image - click here

Improve this question
4
  • Is there antivirus/firewall software that could block the connection?
    – Allen Howard
    Commented Jan 4, 2018 at 16:37
  • No. I don't think so. Additionally, it will sometimes complete the whole download.
    – Shanee Vanstone
    Commented Jan 4, 2018 at 16:46
  • 1
    It looks like a client problem: there are a number of reasons that a client would stop requesting a down-load, running out of disc space being the most obvious; others include running out of RAM for buffering (especially if there is no swap configured) and other programs not allowing the client sufficient CPU time.
    – AFH
    Commented Jan 4, 2018 at 16:51
  • AFH, it probably is client side! Any idea what it might be? The client is stalling in a lwip_read() call (waiting for data), so the buffer shouldn't be full.
    – Shanee Vanstone
    Commented Jan 4, 2018 at 17:15

1 Answer 1

Reset to default
0

The symptoms clearly indicate that there is a client-side receive processing bottleneck.

The trace shows that the receive buffer in the client network stack (LwIP apparently) is filling - Specifically the window size in acknowledgements from the client is shrinking as a series of packets are received from the server, until the receive buffer completely fills and a "ZeroWindow" is sent from client to server to request that it stop sending data.

This typically indicates that the application reading from the socket isn't draining the receive buffer fast enough to let the network stack keep up with the arriving packets.

The frequent Retransmissions from the server, combined with delayed ACKs from client suggest that conditions on the client are also negatively impacting the lower-level receive packet processing in the network stack.

You mentioned the client host was an embedded device, and also commented that your app appears to be blocked at lwip_read(). The wait suggests that another IO or CPU resource or scheduling bottleneck could be preventing your read thread from getting enough CPU time to keep up with the file transfer. However the delayed ACKs suggest that there may be a broader problem. Without knowing more about the embedded device it's difficult to troubleshoot further.

LwIP also has special constraints relating to servicing network calls that could apply to your implementation - See this LwIP pitfalls page.

I hope this information is helpful for resolving your issue.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .