From: Stephen Hemminger <shemminger@vyatta.com>
To: "Adam Langley" <agl@imperialviolet.org>
Cc: "Maxim Levitsky" <maximlevitsky@gmail.com>, netdev@vger.kernel.org
Subject: Re: How I can reset TCP sockets after long suspend/resume cyscle
Date: Wed, 4 Jun 2008 09:21:54 -0700 [thread overview]
Message-ID: <20080604092154.7511c9d3@extreme> (raw)
In-Reply-To: <396556a20806040909q7e5eb8abi7cbc8b5ed11ed54e@mail.gmail.com>
On Wed, 4 Jun 2008 09:09:29 -0700
"Adam Langley" <agl@imperialviolet.org> wrote:
> On Wed, Jun 4, 2008 at 8:34 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> Is there a way to close all TCP sockets before/after suspend to ram?
>
> As with most things, you should consider how this can be done from
> userspace first.
>
> You can find the processes with TCP connections open by walking
> /proc/*/fd and readlink()ing the dents therein. Then you can match the
> inode numbers up with /proc/net/tcp to see if the given TCP connection
> is remote or not.
>
> Now you want to kill those connections somehow. You could imagine
> doing it by injecting RST packets back into the kernel, but for that
> you would need to know the SEQ/ACK numbers for the connection. Since
> that's sensitive information, /proc/net/tcp doesn't carry it. It would
> have to be CAP_NET_ADMIN (read: root user) only and changing the
> formats of proc files based on the reading user is a no-no. So that
> would require another proc file; I've no idea how well that patch
> would be received.
>
> Another option would be to close the TCP connections from within the
> processes which have them. You could enumerate the processes, ptrace
> attach each one, wait() for SIGSTOP, get the current instr pointer and
> patch in some code to close the fds then unpatch the process and let
> it continue. That would be architecture specific, of couse.
>
> When the process comes to reading/selecting the fds again it would get
> a 0 read and act like they had been closed.
>
> I'll admit that neither solution is terribly wonderful.
>
>
> AGL
TCP should recover from this anyway. As soon as any activity happens
on the connection the other end will respond with reset. For an IMAP
session doing the next get-mail should cause a connection reset.
Now it is possible that mail client has other problems.
>
next prev parent reply other threads:[~2008-06-04 16:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-01 12:15 How I can reset TCP sockets after long suspend/resume cyscle Maxim Levitsky
2008-06-04 15:34 ` Maxim Levitsky
2008-06-04 16:09 ` Adam Langley
2008-06-04 16:21 ` Stephen Hemminger [this message]
2008-06-04 21:00 ` Maxim Levitsky
2008-06-04 21:02 ` Rick Jones
2008-06-04 20:52 ` Maxim Levitsky
2008-06-04 21:15 ` Stephen Hemminger
2008-06-04 21:23 ` Rick Jones
2008-06-05 21:31 ` Maxim Levitsky
2008-06-05 21:50 ` Rick Jones
2008-06-06 8:37 ` Benny Amorsen
2008-06-06 9:27 ` Nadejda Levitsky
2008-06-05 7:13 ` Evgeniy Polyakov
2008-06-05 21:19 ` Maxim Levitsky
2008-06-05 22:20 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080604092154.7511c9d3@extreme \
--to=shemminger@vyatta.com \
--cc=agl@imperialviolet.org \
--cc=maximlevitsky@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).