Date:	Fri, 20 Nov 2015 10:55:13 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
	Maciej Żenczykowski <maze@...gle.com>,
	Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Fri, Nov 20, 2015 at 9:55 AM, David Miller <davem@...emloft.net> wrote:
> Netfilter could perform signalling on skb->sk when it drops packets.
>
> Your example is actually a argument _for_ doing this in the kernel.
>
> :-)

Well, I did say that was a simple example. :-) How do I make the VPN
case work? In that case, the packets will go out just fine, they'll
just be sent through the VPN tunnel and get dropped by the VPN server.
Again, the issue there is:

1. TCP connection is established on wifi network.
2. VPN comes up, adds high-priority routing rule that ensures that no
unprivileged app traffic leaks to the wifi network directly, but
everything is sent on VPN.
3. Any packet sent on TCP connection in #1 is now sent on VPN network
with wifi source address.

We don't have a solution for this today; SIOCKILLADDR only takes an IP
address. Today, apps just get stuck. We could fix this with
SOCK_DESTROY.

Here's another thing that could be fixed with SOCK_DESTROY. Today,
when the device switches from cell data to wifi, it tears down cell
data after a 30-second seamless handover period. One major reason to
do this is that if it doesn't, some already-established, long-lived
TCP connection might continue to use expensive cell data because the
app did not close the connection and reconnect on wifi.

If we had SOCK_DESTROY, the system could instead do the following:

1. Device connects to wifi.
2. After 30-second seamless handover, sockets currently established on
cell get closed by SOCK_DESTROY (instead of being closed by tearing
down cell data and calling SIOCKILLADDR). As happens today, apps see
the error and reconnect, and policy steers them to wifi.
3. Unlike today, cell stays up, so that the next time the user needs
it (fast network switching? multipath? app that already has permission
to use cell data?), it's already there and the user doesn't need to
wait 500ms for it to come up again.
4. Unprivileged apps can't use expensive mobile data any more than
they could in previous releases.

As a more general point, I think part of the issue is that there are
lots of problems in the mobile space that might not be immediately
obvious to people on this list. In the past, this has led to us
(Android networking team) proposing non-trivial patches that provided
functionality that makes sense on a mobile device (e.g., UID-based
routing, SOCK_DESTROY), and those patches being rejected on the
grounds that the use cases didn't make sense or that the people
proposing them didn't understand networking. :-)

Better communication might help. I will try to publicly document how
we currently use the stack; hopefully that will provide more context
for discussions such as these, and allow future work to unwind some of
the out-of-tree hacks that we currently rely on and replace it with
upstream alternatives. We might even be able to show up at netdev 1.1
for some higher-bandwidth conversations.
--
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

Powered by blists - more mailing lists