On Tue, 2015-02-03 at 16:19 -0800, David Miller wrote:
> From: David Woodhouse
> 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 k
From: David Woodhouse
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 I have discussed
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
> > 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 t
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 rce
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 ver
On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote:
> From: David Woodhouse
> 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".
>
>
From: David Woodhouse
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 userspace,
and t
On Sun, 2015-02-01 at 12:19 -0800, David Miller wrote:
> From: David Woodhouse
> 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
From: David Woodhouse
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
> down to the kernel
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
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 int
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 owner
14 matches
Mail list logo
