TCP keep-alive parameters not being honoured
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
I have a server running on my Linux box, also on which the following commands were run:
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
My server listens on port 58080, and I create a connection on it having set TCP keep-alive in my code. I then set Wireshark tracing this connection; a screenshot of the output is shown below:
You can see that the first keep-alive packet is sent after 7200 seconds, or 2 hours as expected (the value of 'tcp_keepalive_time'). However I would also expect each probe to be sent at 75 seconds (the value of 'tcp_keepalive_intvl'); what I see though is that each probe is sent at 2 hours.
Can someone please tell me why my configuration option for 'tcp_keepalive_intvl' is not being honoured?
UPDATE
It seems that specifying a keep-alive interval that is greater than the keep-alive time results in the interval time being adhered to...
tcp tcp-ip
asked Mar 11 '17 at 21:19
Wad
1315
add a comment |
up vote
4
down vote
favorite
I have a server running on my Linux box, also on which the following commands were run:
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
My server listens on port 58080, and I create a connection on it having set TCP keep-alive in my code. I then set Wireshark tracing this connection; a screenshot of the output is shown below:
You can see that the first keep-alive packet is sent after 7200 seconds, or 2 hours as expected (the value of 'tcp_keepalive_time'). However I would also expect each probe to be sent at 75 seconds (the value of 'tcp_keepalive_intvl'); what I see though is that each probe is sent at 2 hours.
Can someone please tell me why my configuration option for 'tcp_keepalive_intvl' is not being honoured?
UPDATE
It seems that specifying a keep-alive interval that is greater than the keep-alive time results in the interval time being adhered to...
tcp tcp-ip
asked Mar 11 '17 at 21:19
Wad
1315
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I have a server running on my Linux box, also on which the following commands were run:
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
My server listens on port 58080, and I create a connection on it having set TCP keep-alive in my code. I then set Wireshark tracing this connection; a screenshot of the output is shown below:
You can see that the first keep-alive packet is sent after 7200 seconds, or 2 hours as expected (the value of 'tcp_keepalive_time'). However I would also expect each probe to be sent at 75 seconds (the value of 'tcp_keepalive_intvl'); what I see though is that each probe is sent at 2 hours.
Can someone please tell me why my configuration option for 'tcp_keepalive_intvl' is not being honoured?
UPDATE
It seems that specifying a keep-alive interval that is greater than the keep-alive time results in the interval time being adhered to...
tcp tcp-ip
asked Mar 11 '17 at 21:19
Wad
1315
I have a server running on my Linux box, also on which the following commands were run:
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
My server listens on port 58080, and I create a connection on it having set TCP keep-alive in my code. I then set Wireshark tracing this connection; a screenshot of the output is shown below:
You can see that the first keep-alive packet is sent after 7200 seconds, or 2 hours as expected (the value of 'tcp_keepalive_time'). However I would also expect each probe to be sent at 75 seconds (the value of 'tcp_keepalive_intvl'); what I see though is that each probe is sent at 2 hours.
Can someone please tell me why my configuration option for 'tcp_keepalive_intvl' is not being honoured?
UPDATE
It seems that specifying a keep-alive interval that is greater than the keep-alive time results in the interval time being adhered to...
tcp tcp-ip
tcp tcp-ip
asked Mar 11 '17 at 21:19
Wad
1315
asked Mar 11 '17 at 21:19
Wad
1315
edited Mar 13 '17 at 21:07
asked Mar 11 '17 at 21:19
Wad
1315
asked Mar 11 '17 at 21:19
Wad
1315
asked Mar 11 '17 at 21:19
Wad
1315
1315
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
After discussion with a super-smart colleague, we think we have figured out what's wrong, but are yet to prove this. What is likely happening is that the keep-alive interval is only taken into account when no keep-alive ACK is received. So after 2 hours, if no ACK was received to this first keep-alive packet, a second packet would be sent after 75 seconds and repeatedly at 75 second intervals until an ACK was received.
It turns out that the reason the interval is taken into account only when it is greater than the keep-alive time is due to the way the Linux keep-alive mechanism works, as described on my other question.
edited May 23 '17 at 12:39
Community♦
1
answered Mar 15 '17 at 15:48
Wad
1315
add a comment |
up vote
0
down vote
Indeed, from the documentation :
tcp_keepalive_time
the interval between the last data packet sent (simple ACKs are not
considered data) and the first keepalive probe; after the connection
is marked to need keepalive, this counter is not used any further
tcp_keepalive_intvl
the interval between subsequential keepalive probes, regardless of
what the connection has exchanged in the meantime
tcp_keepalive_probes
the number of unacknowledged probes to send before considering the
connection dead and notifying the application layer
answered Dec 4 at 20:13
Jules Thuillier
1
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f350802%2ftcp-keep-alive-parameters-not-being-honoured%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
After discussion with a super-smart colleague, we think we have figured out what's wrong, but are yet to prove this. What is likely happening is that the keep-alive interval is only taken into account when no keep-alive ACK is received. So after 2 hours, if no ACK was received to this first keep-alive packet, a second packet would be sent after 75 seconds and repeatedly at 75 second intervals until an ACK was received.
It turns out that the reason the interval is taken into account only when it is greater than the keep-alive time is due to the way the Linux keep-alive mechanism works, as described on my other question.
edited May 23 '17 at 12:39
Community♦
1
answered Mar 15 '17 at 15:48
Wad
1315
add a comment |
up vote
1
down vote
accepted
After discussion with a super-smart colleague, we think we have figured out what's wrong, but are yet to prove this. What is likely happening is that the keep-alive interval is only taken into account when no keep-alive ACK is received. So after 2 hours, if no ACK was received to this first keep-alive packet, a second packet would be sent after 75 seconds and repeatedly at 75 second intervals until an ACK was received.
It turns out that the reason the interval is taken into account only when it is greater than the keep-alive time is due to the way the Linux keep-alive mechanism works, as described on my other question.
edited May 23 '17 at 12:39
Community♦
1
answered Mar 15 '17 at 15:48
Wad
1315
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
After discussion with a super-smart colleague, we think we have figured out what's wrong, but are yet to prove this. What is likely happening is that the keep-alive interval is only taken into account when no keep-alive ACK is received. So after 2 hours, if no ACK was received to this first keep-alive packet, a second packet would be sent after 75 seconds and repeatedly at 75 second intervals until an ACK was received.
It turns out that the reason the interval is taken into account only when it is greater than the keep-alive time is due to the way the Linux keep-alive mechanism works, as described on my other question.
edited May 23 '17 at 12:39
Community♦
1
answered Mar 15 '17 at 15:48
Wad
1315
After discussion with a super-smart colleague, we think we have figured out what's wrong, but are yet to prove this. What is likely happening is that the keep-alive interval is only taken into account when no keep-alive ACK is received. So after 2 hours, if no ACK was received to this first keep-alive packet, a second packet would be sent after 75 seconds and repeatedly at 75 second intervals until an ACK was received.
It turns out that the reason the interval is taken into account only when it is greater than the keep-alive time is due to the way the Linux keep-alive mechanism works, as described on my other question.
edited May 23 '17 at 12:39
Community♦
1
answered Mar 15 '17 at 15:48
Wad
1315
edited May 23 '17 at 12:39
Community♦
1
edited May 23 '17 at 12:39
Community♦
1
edited May 23 '17 at 12:39
Community♦
1
1
answered Mar 15 '17 at 15:48
Wad
1315
answered Mar 15 '17 at 15:48
Wad
1315
answered Mar 15 '17 at 15:48
Wad
1315
1315
add a comment |
add a comment |
up vote
0
down vote
Indeed, from the documentation :
tcp_keepalive_time
the interval between the last data packet sent (simple ACKs are not
considered data) and the first keepalive probe; after the connection
is marked to need keepalive, this counter is not used any further
tcp_keepalive_intvl
the interval between subsequential keepalive probes, regardless of
what the connection has exchanged in the meantime
tcp_keepalive_probes
the number of unacknowledged probes to send before considering the
connection dead and notifying the application layer
answered Dec 4 at 20:13
Jules Thuillier
1
add a comment |
up vote
0
down vote
Indeed, from the documentation :
tcp_keepalive_time
the interval between the last data packet sent (simple ACKs are not
considered data) and the first keepalive probe; after the connection
is marked to need keepalive, this counter is not used any further
tcp_keepalive_intvl
the interval between subsequential keepalive probes, regardless of
what the connection has exchanged in the meantime
tcp_keepalive_probes
the number of unacknowledged probes to send before considering the
connection dead and notifying the application layer
answered Dec 4 at 20:13
Jules Thuillier
1
add a comment |
up vote
0
down vote
up vote
0
down vote
Indeed, from the documentation :
tcp_keepalive_time
the interval between the last data packet sent (simple ACKs are not
considered data) and the first keepalive probe; after the connection
is marked to need keepalive, this counter is not used any further
tcp_keepalive_intvl
the interval between subsequential keepalive probes, regardless of
what the connection has exchanged in the meantime
tcp_keepalive_probes
the number of unacknowledged probes to send before considering the
connection dead and notifying the application layer
answered Dec 4 at 20:13
Jules Thuillier
1
Indeed, from the documentation :
tcp_keepalive_time
the interval between the last data packet sent (simple ACKs are not
considered data) and the first keepalive probe; after the connection
is marked to need keepalive, this counter is not used any further
tcp_keepalive_intvl
the interval between subsequential keepalive probes, regardless of
what the connection has exchanged in the meantime
tcp_keepalive_probes
the number of unacknowledged probes to send before considering the
connection dead and notifying the application layer
answered Dec 4 at 20:13
Jules Thuillier
1
answered Dec 4 at 20:13
Jules Thuillier
1
answered Dec 4 at 20:13
Jules Thuillier
1
answered Dec 4 at 20:13
Jules Thuillier
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f350802%2ftcp-keep-alive-parameters-not-being-honoured%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
