From: Daniel Baluta <dbaluta@ixiacom•com>
To: Steffen Klassert <steffen.klassert@secunet•com>
Cc: David Miller <davem@davemloft•net>, <nicolas.dichtel@6wind•com>,
<herbert@gondor•apana.org.au>, <netdev@vger•kernel.org>
Subject: Re: [RFC PATCH ipsec] xfrm: use the right dev to fill xdst
Date: Wed, 10 Apr 2013 14:39:39 +0300 [thread overview]
Message-ID: <51654F7B.20805@ixiacom.com> (raw)
In-Reply-To: <20130410112900.GC21448@secunet.com>
On 04/10/2013 02:29 PM, Steffen Klassert wrote:
> On Tue, Apr 09, 2013 at 09:18:33PM +0300, Daniel Baluta wrote:
>> On Tue, Apr 9, 2013 at 8:33 PM, David Miller<davem@davemloft•net> wrote:
>>> From: Daniel Baluta<daniel.baluta@gmail•com>
>>> Date: Tue, 9 Apr 2013 20:31:30 +0300
>>>
>>>> As I mentioned earlier in this thread we are using some custom
>>>> kernel modules that create the interfaces.
>>>>
>>>> It's likely that these interfaces, for memory saving purposes, to
>>>> skip attaching ipv6 device information.
>>> So this is not an upstream bug.
>> Correct.
>>
>> With conditions mentioned by Steffen, in upstream, each net_device
>> has an in6_device assigned so we won't hit the problem.
>>
> We have an in6_device assigned in almost all of the cases, but I doubt
> it is always the right one.
>
> Let's say we want to tunnel ipv6 over ipv4. We do an ipv6 route lookup
> that returns a route with output device, say eth0. With that route,
> we do an IPsec route lookup and we get an ipv4 tunnel route with output
> device eth1.
>
> When we create the xfrm_dst in xfrm_bundle_create(), we copy the
> informations from the original ipv6 route, because we pass the new
> allocated IPsec route back to the ipv6 layer. But the device is taken
> from the ipv4 tunnel route (eth1 instead of eth0), so we pass a
> dst_entry with a ipv4 device assigned to the ipv6 layer.
>
> For that reason, xfrm6_fill_dst() complains about a NULL in6_device,
> when the mtu of the ipv4 device (passed to xfrm6_fill_dst()) is
> below IPV6_MIN_MTU.
>
> I think there is to fix something, but this needs some more research
> before we can do anything about that.
>
I will try to further look into this. If you have any scripts
that can ease IPSec tunnels setup please do share.
thanks,
daniel.
prev parent reply other threads:[~2013-04-10 11:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 15:12 [RFC PATCH ipsec] xfrm: use the right dev to fill xdst Nicolas Dichtel
2013-04-05 9:46 ` Steffen Klassert
2013-04-05 12:59 ` Daniel Baluta
2013-04-08 11:42 ` Steffen Klassert
2013-04-09 12:47 ` Steffen Klassert
2013-04-09 17:21 ` David Miller
2013-04-09 17:31 ` Daniel Baluta
2013-04-09 17:33 ` David Miller
2013-04-09 18:18 ` Daniel Baluta
2013-04-10 11:29 ` Steffen Klassert
2013-04-10 11:39 ` Daniel Baluta [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51654F7B.20805@ixiacom.com \
--to=dbaluta@ixiacom$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=steffen.klassert@secunet$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox