Linux doesn't close TCP connection after change a Wi-Fi network
up vote
1
down vote
favorite
1
There is some TCP connection between some device behind NAT (Wi-Fi router) and server, located in Google Cloud, both under Ubuntu 16.04. When I changed a Wi-Fi network, this device keeps this connection in "ESTABLISHED" state, though the server drops it.
Before change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
tcp 0 0 10.142.X.X:8080 73.XXX.XXX.XXX:49514 ESTABLISHED 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
After change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
Why doesn't my device drop that TCP connection?
Additional info:
TCP keepalive
Server
root@server:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
Client
root@client:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
linux networking wireless-networking tcp cloud
asked Dec 5 at 21:35
Vladimir Karnushin
64
add a comment |
up vote
1
down vote
favorite
1
There is some TCP connection between some device behind NAT (Wi-Fi router) and server, located in Google Cloud, both under Ubuntu 16.04. When I changed a Wi-Fi network, this device keeps this connection in "ESTABLISHED" state, though the server drops it.
Before change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
tcp 0 0 10.142.X.X:8080 73.XXX.XXX.XXX:49514 ESTABLISHED 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
After change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
Why doesn't my device drop that TCP connection?
Additional info:
TCP keepalive
Server
root@server:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
Client
root@client:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
linux networking wireless-networking tcp cloud
asked Dec 5 at 21:35
Vladimir Karnushin
64
Please include the output ofgrep -H '' /proc/sys/net/ipv4/tcp_keepalive*from both systems (edit this information into the question).
– Kamil Maciorowski
Dec 5 at 22:15
1
As long as neither the client nor the server send aFINand the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...
– tink
Dec 6 at 2:13
add a comment |
up vote
1
down vote
favorite
1
up vote
1
down vote
favorite
1
1
There is some TCP connection between some device behind NAT (Wi-Fi router) and server, located in Google Cloud, both under Ubuntu 16.04. When I changed a Wi-Fi network, this device keeps this connection in "ESTABLISHED" state, though the server drops it.
Before change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
tcp 0 0 10.142.X.X:8080 73.XXX.XXX.XXX:49514 ESTABLISHED 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
After change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
Why doesn't my device drop that TCP connection?
Additional info:
TCP keepalive
Server
root@server:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
Client
root@client:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
linux networking wireless-networking tcp cloud
asked Dec 5 at 21:35
Vladimir Karnushin
64
There is some TCP connection between some device behind NAT (Wi-Fi router) and server, located in Google Cloud, both under Ubuntu 16.04. When I changed a Wi-Fi network, this device keeps this connection in "ESTABLISHED" state, though the server drops it.
Before change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
tcp 0 0 10.142.X.X:8080 73.XXX.XXX.XXX:49514 ESTABLISHED 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
After change:
Server
root@server:~# netstat -natp | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1810/crossbar-worker
Client
root@client:~# netstat -natp | grep 8080
tcp 0 0 192.168.X.X:49514 35.XXX.XXX.XXX:8080 ESTABLISHED 9089/crossbar-worker
Why doesn't my device drop that TCP connection?
Additional info:
TCP keepalive
Server
root@server:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
Client
root@client:~# grep -H '' /proc/sys/net/ipv4/tcp_keepalive*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
linux networking wireless-networking tcp cloud
linux networking wireless-networking tcp cloud
asked Dec 5 at 21:35
Vladimir Karnushin
64
asked Dec 5 at 21:35
Vladimir Karnushin
64
edited Dec 6 at 12:16
asked Dec 5 at 21:35
Vladimir Karnushin
64
asked Dec 5 at 21:35
Vladimir Karnushin
64
asked Dec 5 at 21:35
Vladimir Karnushin
64
64
Please include the output ofgrep -H '' /proc/sys/net/ipv4/tcp_keepalive*from both systems (edit this information into the question).
– Kamil Maciorowski
Dec 5 at 22:15
1
As long as neither the client nor the server send aFINand the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...
– tink
Dec 6 at 2:13
add a comment |
Please include the output ofgrep -H '' /proc/sys/net/ipv4/tcp_keepalive*from both systems (edit this information into the question).
– Kamil Maciorowski
Dec 5 at 22:15
1
As long as neither the client nor the server send aFINand the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...
– tink
Dec 6 at 2:13
Please include the output of
grep -H '' /proc/sys/net/ipv4/tcp_keepalive* from both systems (edit this information into the question).– Kamil Maciorowski
Dec 5 at 22:15
Please include the output of
grep -H '' /proc/sys/net/ipv4/tcp_keepalive* from both systems (edit this information into the question).– Kamil Maciorowski
Dec 5 at 22:15
1
1
As long as neither the client nor the server send a
FIN and the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...– tink
Dec 6 at 2:13
As long as neither the client nor the server send a
FIN and the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...– tink
Dec 6 at 2:13
add a comment |
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
draft saved
draft discarded
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%2fsuperuser.com%2fquestions%2f1381148%2flinux-doesnt-close-tcp-connection-after-change-a-wi-fi-network%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Super User!
- 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.
draft saved
draft discarded
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%2fsuperuser.com%2fquestions%2f1381148%2flinux-doesnt-close-tcp-connection-after-change-a-wi-fi-network%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
Please include the output of
grep -H '' /proc/sys/net/ipv4/tcp_keepalive*from both systems (edit this information into the question).– Kamil Maciorowski
Dec 5 at 22:15
1
As long as neither the client nor the server send a
FINand the timeout (see @KamilMaciorowski 's comment) isn't exceeded the connection stays established ...– tink
Dec 6 at 2:13