Azure Virtual Machines
An Azure service that is used to provision Windows and Linux virtual machines.
7,873 questions
That's ok thank you, I have asked the question via Azure portal.
TCP Connections dropped after approx 5 mins of inactivity
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 4%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMT%3C/text%3E%3C/svg%3E)
Mike Taylor
116
Reputation points
I have the idle timeout set to 20 minutes. However, tests with a Python TCP client talking to a a Python TCP server using "epoll", give me an issue when the idle time is roughly 5 minutes of inactivity. I loose the last packet sent, and get an error thrown from the client when after 10 minutes it tries to close the connection, as follows:-
Traceback (most recent call last):
File "atlas_client.py", line 121, in <module>
make_connection()
File "atlas_client.py", line 111, in make_connection
skt.shutdown(socket.SHUT_RDWR)
OSError: [Errno 107] Transport endpoint is not connected
Running this test locally on my Ubuntu VM, gives no such issue.
I am a bit of a loss as to what to try. I can (I believe) force keep-alive packets, however on a 4g connection when we are paying for each and every byte sent/received I don't really want to do this.
How can I tell whether this is an Azure firewall issue, Ubuntu VM or a problem with my code?
Accepted answer
-
Mike Taylor 116 Reputation points
2020-11-16T19:17:57.58+00:00 -
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 36%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
SaiKishor-MSFT 17,231 Reputation points2020-11-17T01:08:22.71+00:00 Thank you Mike.
Sign in to comment -
9 additional answers
Sort by: Most helpful
-
Mike Taylor 116 Reputation points
2020-11-08T17:30:59.903+00:00 ![38221-screenshot-2020-11-08-172859.png][1]I am still confused as to why the "idle" timeout value on the Azure system can be set to 30 minutes, yet it still drops connections after 5 minutes.
-
SaiKishor-MSFT 17,231 Reputation points
2020-11-09T22:12:35.993+00:00 @Mike Taylor
Thanks for providing the screenshot. I understand that you have configured the timeout value in the public IP address portal. Public IP address has an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and fixed outbound originated flow idle timeout of 4 minutes.So if this flow is outbound originated, you cannot adjust the idle timeout using the portal. The only other option is to use the keepalives option. Please let me know if you have any other questions. Thank you!
-
Mike Taylor 116 Reputation points
2020-11-10T10:26:53.993+00:00 The client (the device on the mobile network) makes a persistent TCP connection to the server running on Azure. I would of therefore expected this to follow the rule of "inbound originated", which is set to 30 minutes. What is actually happening, is that after ~4-5 minutes of inactivity , the connection is dropped, however "netstat" still shows it as being alive.
When after 10 minutes, the client tries to send the next packet of data, it is being lost. Our mobile operator confirms there is no time-out on the SIM and this issue appears to of started since moving the server software to Azure.
I can force it to keep the connection going by enabling keep-alives, however this means more traffic on the wire, which ultimately means more costs to us.
Why, in this instance, would the fixed outbound flow idle period of 4 minutes, be taking precedence?
-
SaiKishor-MSFT 17,231 Reputation points
2020-11-11T00:59:22.69+00:00 @Mike Taylor
Thanks for clarifying the direction of traffic. Could you provide the following details-- Capture of traffic on client and server sides using any packet capture software such as wireshark and let me know what you see between the server and client (if possible please share what you see by removing/altering any sensitive data).
- Can you confirm the type of client and server machines on both sides and the traffic flow between them (i.e., the path and devices they traverse)?
Thank you!
-
Mike Taylor 116 Reputation points
2020-11-11T12:43:18.793+00:00 1/. I tried to attach a pcap (take from tcpdump) from both client and the server, however this server won't allow it, any suggestions? To simplify the situation, this example is not sending real data, but just highlights the problem we are seeing. After 5 minutes, the client will try and send it's next payload of data, which fails and returns a "Transport endpoint is not connected" error.39050-atlas-client.txt
2/. Both the server and the client in this example are simple Python3 scripts. Obviously in real-life, this is not the what we are using. The Quectel modems send data across the 2G mobile network, but again, I have replicated this issue using my broadband connection. Is that what you meant?
Sign in to comment -
-
Mike Taylor 116 Reputation points
2020-11-11T13:08:57.367+00:00 -
SaiKishor-MSFT 17,231 Reputation points
2020-11-11T18:07:42.607+00:00 @Mike Taylor
Thanks for the captures. However, the packets don't seem to match on both sides i.e., they don't belong to the same flow of traffic. I was able to verify this based on the identification number of the IPv4 packets. Could you re-capture it and make sure you do it simultaneously on both sides.From the given captures, I see the client side is receiving a RST for the connection but I don't see the server sending a RST packet to end the connection.
If you prefer to do this troubleshooting directly with a Support Rep over a call, I can give you a onetime free support exception. If this is something you want to do, please let me know your Subscription ID so I can request for the same for you. Thank you!
Sign in to comment -