On Tue, 2015-02-03 at 16:19 -0800, David Miller wrote:
From: David Woodhouse dw...@infradead.org
Date: Mon, 02 Feb 2015 07:27:10 +
I'm guessing you don't want to push the *whole* management of the TLS
control connection *and* the UDP transport, and probing the latter with
keepalives,
From: David Woodhouse dw...@infradead.org
Date: Mon, 02 Feb 2015 07:27:10 +
I'm guessing you don't want to push the *whole* management of the TLS
control connection *and* the UDP transport, and probing the latter with
keepalives, into the kernel? I certainly don't :)
Whilst Herbert Xu and
On Mon, Feb 02, 2015 at 07:27:10AM +, David Woodhouse wrote:
On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote:
We might as well have not have implemented the IPSEC stack at all,
because as a result of the userland VPN stuff our IPSEC stack is
largely unused except by a very
On Mon, 2015-02-02 at 16:23 +0100, Phil Sutter wrote:
Since you want to provide connectivity over HTTPS which is not possible
in kernel space, you are stuck with keeping the tun device. So the
packet flow in that case is identical to how e.g. OpenVPN does it:
- tunX holds default route
-
On Mon, 2015-02-02 at 09:24 +0100, Steffen Klassert wrote:
Maybe you want to use a virtual tunnel interface (vti) what we have
already. Everything that is routed through such an interface is
guaranteed to be either encrypted if a matching xfrm state is present
or dropped. Same on the rceive
Hi,
On Mon, Feb 02, 2015 at 07:27:10AM +, David Woodhouse wrote:
On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote:
From: David Woodhouse dw...@infradead.org
Date: Sun, 01 Feb 2015 21:29:43 +
I really was looking for some way to push down something like an XFRM
state
On Wed, 2010-04-14 at 08:58 +0800, Herbert Xu wrote:
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Herbert Acked your patch, so I guess its OK, but I think it can be
dangerous.
The tun socket accounting was never designed to stop it from
flooding another tun interface.
On Sun, 2015-02-01 at 14:26 +0200, Michael S. Tsirkin wrote:
When I run over the VPN, netperf thinks it sent 2½ times the amount of
TX traffic.
At some level, it's expected: netperf's manual actually says:
A UDP_STREAM test has no end-to-end flow control - UDP provides none and
On Sun, Feb 01, 2015 at 11:20:33AM +, David Woodhouse wrote:
On Wed, 2010-04-14 at 08:58 +0800, Herbert Xu wrote:
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Herbert Acked your patch, so I guess its OK, but I think it can be
dangerous.
The tun socket
On Sun, 2015-02-01 at 12:19 -0800, David Miller wrote:
From: David Woodhouse dw...@infradead.org
Date: Sun, 01 Feb 2015 13:33:50 +
Of course, now I'm looking closely at the path these packets take to
leave the box, it starts to offend me that they're being passed up to
userspace just
From: David Woodhouse dw...@infradead.org
Date: Sun, 01 Feb 2015 13:33:50 +
Of course, now I'm looking closely at the path these packets take to
leave the box, it starts to offend me that they're being passed up to
userspace just to encrypt them (as DTLS or ESP) and then send them back
From: David Woodhouse dw...@infradead.org
Date: Sun, 01 Feb 2015 21:29:43 +
I really was looking for some way to push down something like an XFRM
state into the tun device and just say shove them out here until I tell
you otherwise.
People decided to use TUN and push VPN stuff back into
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.
As noted by Herbert, possible solutions include a timeout followed by a
copy/change of
13 matches
Mail list logo
