On Thu, 24 Sep 2015 00:54:00 -0500, Eric W. Biederman wrote:
> My only interest in this is to help figure out how to make IPv6 ndisc
> work over light weight tunnels.
Thanks for that. However, as much as some of the things you wrote in
this mail make sense (see below), I don't see how they help
Thomas Graf writes:
> On 09/23/15 at 04:09pm, Eric W. Biederman wrote:
>
> [...]
>
>> *Blink* You were targeting net.git with a feature enhancement
>> I will just ignore that.
>
> The point of this series is to not expose the src and dst port Netlink
> bits to user space in a
On Wed, 23 Sep 2015 16:09:14 -0500, Eric W. Biederman wrote:
> *Blink* You were targeting net.git with a feature enhancement
> I will just ignore that.
I do not. This is set is a minimal fix to make IP based lwtunnels with
tunnel information specified in a route working (for IPv4, anyway).
From: Jiri Benc
Date: Tue, 22 Sep 2015 18:12:10 +0200
> One of the selling points of lwtunnel was the ability to specify the tunnel
> destination using routes. However, this doesn't really work currently, as
> ARP and ndisc replies are not handled correctly. ARP and ndisc
Thomas Graf writes:
> On 09/22/15 at 11:39pm, Eric W. Biederman wrote:
>> What distinguishes a skb received from a tunnel as opposed to a skb
>> received on from a network device is that a skb recevied on a tunnel
>> has a socket.
>>
>> I could be easily missing something but
On Wed, 23 Sep 2015 07:17:53 -0500, Eric W. Biederman wrote:
> Assuming the transport is UDP then it would be a UDP socket. That
> socket will have all of the information needed to construct the outer
> header as the receive path of that socket removes the outer header.
>
> I admit you can't use
Jiri Benc writes:
> On Wed, 23 Sep 2015 07:17:53 -0500, Eric W. Biederman wrote:
>> Assuming the transport is UDP then it would be a UDP socket. That
>> socket will have all of the information needed to construct the outer
>> header as the receive path of that socket removes
On 09/22/15 at 11:39pm, Eric W. Biederman wrote:
> What distinguishes a skb received from a tunnel as opposed to a skb
> received on from a network device is that a skb recevied on a tunnel
> has a socket.
>
> I could be easily missing something but couldn't you look at skb->sk
> on the input
On 09/22/15 at 06:12pm, Jiri Benc wrote:
> One of the selling points of lwtunnel was the ability to specify the tunnel
> destination using routes. However, this doesn't really work currently, as
> ARP and ndisc replies are not handled correctly. ARP and ndisc replies won't
> have tunnel metadata
Jiri Benc writes:
> On Wed, 23 Sep 2015 12:42:30 -0500, Eric W. Biederman wrote:
[snip]
>> So perhaps instead of:
>> +if (arp->ar_op == htons(ARPOP_REQUEST) && skb_metadata_dst(skb))
>> +reply_dst = (struct dst_entry *)
>> +
On Wed, 23 Sep 2015 12:42:30 -0500, Eric W. Biederman wrote:
> Without your ARP changes in this patchset I don't understand what the
> purpose of metadata dsts are, so I am probably still missing something
> important.
>
> If ARP and ndisc are the only uses of metadata dsts, allocating a
>
On 09/23/15 at 04:09pm, Eric W. Biederman wrote:
[...]
> *Blink* You were targeting net.git with a feature enhancement
> I will just ignore that.
The point of this series is to not expose the src and dst port Netlink
bits to user space in a released kernel because the ABI is not set in
One of the selling points of lwtunnel was the ability to specify the tunnel
destination using routes. However, this doesn't really work currently, as
ARP and ndisc replies are not handled correctly. ARP and ndisc replies won't
have tunnel metadata attached, thus they will be sent out with the
Jiri Benc writes:
> One of the selling points of lwtunnel was the ability to specify the tunnel
> destination using routes. However, this doesn't really work currently, as
> ARP and ndisc replies are not handled correctly. ARP and ndisc replies won't
> have tunnel metadata
14 matches
Mail list logo