netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).