From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: stefan@agner.ch Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id e7024930 for ; Wed, 4 Jul 2018 21:58:15 +0000 (UTC) Received: from mail.kmu-office.ch (mail.kmu-office.ch [IPv6:2a02:418:6a02::a2]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 2979d47f for ; Wed, 4 Jul 2018 21:58:15 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Jul 2018 00:04:51 +0200 From: Stefan Agner To: "Jason A. Donenfeld" Subject: Re: Android: TCP connection drop when disabling WiFi In-Reply-To: References: Message-ID: Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 04.07.2018 23:13, Jason A. Donenfeld wrote: > Hi Stefan, > > I wish this were the case too, but Android sends SOCK_DESTROY to > everything when networks change, and there isn't a lot that can be > done about it without rooting the device, as far as I can tell. If > you've got some Android chops and can think of a way we can suppress > that, I'd be very interested. Ugh, so as I expected :-( Unfortunately, I am not very familiar with Android. It seems that Android only kills connection when addresses get removed. The data connection stays on in background, so that is why 4G -> WiFi works: No addresses get removed. Same behavior when using "Always-on VPN" or "Block connections without VPN". It really seems a silly behavior in the light of VPNs. With SOCK_DESTROY I pretty quickly found netd and the code which actually causes the connection drop. It seems to me that only connections with an address which actually gets removed get dropped NetlinkHandler::onEvent), but maybe I don't understand the full picture. And after some more digging I found this commit with the promising title "Do not destroy socket when VPN interface address is still in use": https://android.googlesource.com/platform/system/netd/+/6c00b61656da32ce3223a2fc711f5649b6b7b5ac However, it seems to me that this is not relly applicable in the Wireguard case... -- Stefan