netdev - Re: How I can reset TCP sockets after long suspend/resume cyscle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080604092154.7511c9d3@extreme>
Date:	Wed, 4 Jun 2008 09:21:54 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	"Adam Langley" <agl@...erialviolet.org>
Cc:	"Maxim Levitsky" <maximlevitsky@...il.com>, netdev@...r.kernel.org
Subject: Re: How I can reset TCP sockets after long suspend/resume cyscle

On Wed, 4 Jun 2008 09:09:29 -0700
"Adam Langley" <agl@...erialviolet.org> wrote:

> On Wed, Jun 4, 2008 at 8:34 AM, Maxim Levitsky <maximlevitsky@...il.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.

> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html