From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Adam Langley <agl@imperialviolet.org>
Cc: netdev@vger.kernel.org
Subject: Re: How I can reset TCP sockets after long suspend/resume cyscle
Date: Wed, 04 Jun 2008 23:52:54 +0300 [thread overview]
Message-ID: <484700A6.3020707@gmail.com> (raw)
In-Reply-To: <396556a20806040909q7e5eb8abi7cbc8b5ed11ed54e@mail.gmail.com>
Adam Langley 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.
This isn't a problem, since suspend/resume is done by root.
I was thinking about something like that, and thought that it is
implemented, so I asked here.
So small question, as a root, I can get SEQ/ACK numbers of a connection?
I am thinking, that maybe such thing can be put in kernel (as optional
feature)
I can even add a suspend timeout, so if suspend was longer that it, then
reset the sockets, otherwise not.
setting the timeout to 0 (default) will disable the feature.
>
> 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
>
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2008-06-04 20:52 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
2008-06-04 21:00 ` Maxim Levitsky
2008-06-04 21:02 ` Rick Jones
2008-06-04 20:52 ` Maxim Levitsky [this message]
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=484700A6.3020707@gmail.com \
--to=maximlevitsky@gmail.com \
--cc=agl@imperialviolet.org \
--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).