From: Steffen Klassert <steffen.klassert@secunet.com>
To: Daniel Baluta <dbaluta@ixiacom.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>,
herbert@gondor.apana.org.au, davem@davemloft.net,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH ipsec] xfrm: use the right dev to fill xdst
Date: Tue, 9 Apr 2013 14:47:35 +0200 [thread overview]
Message-ID: <20130409124735.GA21448@secunet.com> (raw)
In-Reply-To: <CAEnQRZDUjaL56AggThN50sYJpA8diQdQ85D4xCqpwtv8PbR7mg@mail.gmail.com>
On Fri, Apr 05, 2013 at 03:59:59PM +0300, Daniel Baluta wrote:
> On Fri, Apr 5, 2013 at 12:46 PM, Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> > On Thu, Apr 04, 2013 at 05:12:42PM +0200, Nicolas Dichtel wrote:
> >> Commit bc8e4b954e46 (xfrm6: ensure to use the same dev when building a bundle)
> >> broke IPsec for IPv4 over IPv6 tunnels (because dev points to an IPv4 only
> >> interface, hence in6_dev_get(dev) returns NULL.
> >
> > Can you give some informations on how to reproduce this? I'm running
> > interfamily tunnels on our testing environment and it seems to
> > work fine.
>
> I can hit this in our setup while using some internal custom simulated
> interfaces.
>
> Anyhow, this should be reproducible with a classic IPv6 IPsec over
> IPv4 test. Please make sure
> that the IPv4 interface doesn't have an IPv6 address set up.
>
> Quoting from commit bc8e4b954e46 (xfrm6: ensure to use the same dev
> when building a bundle):
>
> - xdst->u.rt6.rt6i_idev = in6_dev_get(rt->u.dst.dev);
> + xdst->u.rt6.rt6i_idev = in6_dev_get(dev);
>
> dev points to IPv4 endpoint and if it doesn't have an IPv6 address
> associated then
> in6_dev_get(dev) will return NULL.
Hm, inet6_init() registers addrconf_notify() as a netdevice notifier
function. So addrconf_notify() is called whenever a netdevice is
registered. When looking at addrconf_notify(), there are only two
cases when the net_device has no inet6_dev assigned. This is either
on error, or if the device mtu is smaller than IPV6_MIN_MTU (i.e. 1280).
I can reproduce the behaviour you describe if I set the mtu of the
ipv4 device to a value below IPV6_MIN_MTU, but in no other case.
Is it possible that your ipv4 device has a mtu below IPV6_MIN_MTU?
next prev parent reply other threads:[~2013-04-09 12:47 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 [this message]
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
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=20130409124735.GA21448@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.