netdev - Re: Bug? TCP shutdown behaviour when deleting local IP addresses

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: <alpine.DEB.2.00.1210181151040.21297@uplift.swm.pp.se>
Date:	Thu, 18 Oct 2012 11:58:01 +0200 (CEST)
From:	Mikael Abrahamsson <swmike@....pp.se>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	Chris Friesen <chris.friesen@...band.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Patrick McHardy <kaber@...sh.net>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: Bug?  TCP shutdown behaviour when deleting local IP addresses

On Thu, 18 Oct 2012, Eric Dumazet wrote:

>> After resume (or otherwise network connectivity re-established),
>> connection manager should be able to tell the kernel to:
>>
>> a) kill all TCP/UDP/other sessions existing which doesn't currently have
>> an active IP address on the machine. This is for the sake of local
>> clients.
>
> You do realize kernel has no idea that the loss of IP address is
> temporary or not ?

Indeed, that's why I wrote "connection manager tell the kernel to..", and 
didn't write "the kernel should do".

> Some links can be slow to setup after a resume.

Absolutely.

>> b) the TCP/SCTP sessions that *do* have an IP, should have their
>> retransmit timers "reset", so that whatever needs to be sent, should be
>> sent immediately (or shortly, within a few seconds).
>
> So they are going to force a close, even if the link becomes alive after
> 15 seconds. Too bad for some wireless setups, or tunnels.

I don't get what you're saying. I'm saying reset the retransmit timers, if 
there is no response, exponential backoff applies again. The reset of the 
timers is to avoid that the exponential backoff timer is now in "wait for 
several minutes to send the next packet" due to no connectivity during the 
first 10-20 seconds after coming out of resume.

On my Ubuntu 12.04 system, when I bring it out of resume and press enter 
in the terminal with an established ssh session, it takes minutes to 
discover that this session doesn't work and close it (it seems the TCP RST 
from the server isn't triggered for a long time). I usually end up killing 
the ssh process on the laptop and logging in again. What I want to happen 
is that within a few seconds of network connectivity being established, 
TCP should try to communicate and discover that the other end already 
closed the connection and close the local socket call so ssh quits and I 
can re-login again. One way of doing this would be for the connection 
manager to ask the kernel to reset (or severely lower) the retransmit 
timers on all established TCP connections.

-- 
Mikael Abrahamsson    email: swmike@....pp.se
--
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