From: Steffen Klassert <steffen.klassert@secunet.com>
To: Daniel Baluta <dbaluta@ixiacom.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 13:29:00 +0200 [thread overview]
Message-ID: <20130410112900.GC21448@secunet.com> (raw)
In-Reply-To: <CAEnQRZBLLUviOrgQxzA=X9Q6YpSq9vf8kBtgPxeTiitS+P-oFw@mail.gmail.com>
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.
next prev parent reply other threads:[~2013-04-10 11:29 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 [this message]
2013-04-10 11:39 ` Daniel Baluta
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=20130410112900.GC21448@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=dbaluta@ixiacom.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).