Argthtjtr

I am on server 192.168.0.2 and want to make an HTTP call to 192.168.0.1(both servers are RPis and run Linux (raspbian)).

curl -XGET http://192.168.0.1:8081/api

The API on 192.168.0.1 (which I am calling) is mine (a Python script based on bottle) and works most of the time. The HTTP listening part sometimes mysteriously hangs, which results with the curl call above hanging, then timing out.

I ran tcpdump on 192.168.0.1 (the receiving server, the one which hosts the API) when the API was non responsive and the wireshark analysis shows some retransmissions right after the call is initiated:

What is usually the cause of such behaviour? (if there is a "usual" cause).

Note 1: If needed, I will modify the API so that it logs more data for the webserver part but due to the non-reproducible nature of the hang, I doubt that it is its fault (the other pieces (threads) work great and there is no crash of any thread).

Note 2: rebooting the server (also probably restarting the script itself (which I do not do as I rather reboot the machine)) fixes the problem.

What does a sequence of retransmissions with PSH,ACK flags mean (and a spurious retransmission back)?

What is usually the cause of such behaviour? (if there is a "usual"
cause).

PSH ACK Wireshark Trace

(Also See ServerFault - PHA ACK During My
Connection)

ACK means that the machine sending the packet with ACK is
acknowledging data that it had received from the other machine. In
TCP, once the connection is established, all packets sent by either
side will contain an ACK, even if it's just re-acknowledging data that
it's already acknowledged.

PSH is an indication by the sender that, if the receiving machine's
TCP implementation has not yet provided the data it's received to the
code that's reading the data (program, or library used by a program),
it should do so at that point. To quote RFC 793, the official
specification for TCP:

The data that flows on a connection may be thought of as a stream of
octets. The sending user indicates in each SEND call whether the data
in that call (and any preceeding calls) should be immediately pushed
through to the receiving user by the setting of the PUSH flag.

A sending TCP is allowed to collect data from the sending user and to
send that data in segments at its own convenience, until the push
function is signaled, then it must send all unsent data. When a
receiving TCP sees the PUSH flag, it must not wait for more data from
the sending TCP before passing the data to the receiving process.

Spurious Retransmissions

If you’re seeing spurious retransmissions it means that the sender
thought packets were lost and sent them again, even though the
receiver sent an acknowledge packet for it.

Possible Causes

• A misconfiguration between the server and client machines


• A misconfiguration between any sender and receiver anywhere along the hop path the of TCP packets


• Firewall rules or packet filters blocking packets

Additonal Troubleshooting

• Check the server logs when this occurs as well


• Run the TCP trace with Wireshark on the server to see what those packets look like when the problem occurs