** Changed in: ifupdown (Ubuntu)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1609367
Title:
ifupdown does not set ipv6-only
** Bug watch removed: Debian Bug tracker #809714
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809714
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1609367
Title:
> I believe the decision is to add the scripts to ifupdown in y or z
only (no SRU)
or, we can just close this as wontfix and explain how to work around
this by adding a manual inet section with the increased mtu value, since
that's quite easy to do when manually configuring ifupdown.
--
You
To follow up, I believe the decision is to add the scripts to ifupdown
in y or z only (no SRU), and fix this for older releases in curtin via
bug 1609861.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
** Branch linked: lp:curtin
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1609367
Title:
ifupdown does not set ipv6-only large mtu
Status in ifupdown package in
** Branch linked: lp:~raharper/curtin/trunk.more-ipv6
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1609367
Title:
ifupdown does not set ipv6-only large mtu
Status in
> While we could see about getting the script included in yakkety (or y+1);
> curtin will still need to
> handle this unless we want to SRU ifdowndown in precise, trusty and
> xenial. This has an enormous
> impact; so it's not something we should take lightly.
As long as curtin handles it
Hi Dan,
Yes; I have a curtin modification and test-cases to handle all of our
scenarios.
https://code.launchpad.net/~raharper/curtin/trunk.more-ipv6
In particular, you can see the final scripts (a pre-hook and post is
needed)
http://bazaar.launchpad.net/~raharper/curtin/trunk.more-
Ryan are you working on adding the script to ifupdown in ubuntu and/or
debian?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1609367
Title:
ifupdown does not set
> if we have a higher mtu onthe ipv6 link, like 4800, then the inet section
> mtu setting clobbers it and they both end up at 1500.
>
> Now, that case I still believe is *invalid* configuration;
I agree - if the ifupdown config has the inet mtu set lower than the
inet6 mtu, that's a
** Changed in: ifupdown (Ubuntu)
Importance: Undecided => Medium
** Changed in: ifupdown (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
On Tue, Aug 9, 2016 at 12:56 PM, Dan Streetman <
dan.streetman+launch...@canonical.com> wrote:
> > I understand this scenario; however, what I don't understand is why
> > if we're setting mtu 9002 on the underlying devices, why the mtu on the
> > "virtual" device (bond0)
> > matters vs. the mtu
> I understand this scenario; however, what I don't understand is why
> if we're setting mtu 9002 on the underlying devices, why the mtu on the
> "virtual" device (bond0)
> matters vs. the mtu setting of the ipv6 link, especially since this is ipv6
> only.
I think the slave interface mtu will be
There also seems to be another bug for ipv6 only; the sysctl setting of
mtu happens before the ip link set dev up; which means, at up time, the
interface gets the default mtu which clobbers the ipv6 mtu.
/sbin/sysctl -q -e -w net.ipv6.conf.ens8.autoconf=0
/sbin/sysctl -q -e -w
On Thu, Aug 4, 2016 at 5:21 PM, Dan Streetman <
dan.streetman+launch...@canonical.com> wrote:
> > In the original bug where one is comparing ip output of MTU; is there
> something *not* working ?
>
> in that original bug, the user is trying to set up ipv6 tunneling:
>
> "This scenario is quiet
> In the original bug where one is comparing ip output of MTU; is there
something *not* working ?
in that original bug, the user is trying to set up ipv6 tunneling:
"This scenario is quiet common when using tunnels (e.g. Sixxs) to provide IPv6
connectivity. My IPv6 MTU needs to be 20 bytes
> and the tl;dr is that IPv6 supports per protocol, rather than
interface.
the ipv6 mtu is for situations where the host's ipv6 connection uses (at
some point down the line) ipv6 tunneling, for example 6in4 or 6rd. The
ipv6 mtu is strictly a subset of the device mtu; it can never be more
than
Can you explain which part fails?
"ifupdown fails to set the device's mtu, which causes its attempt to set
the ipv6 mtu to fail"
This is the change that drove the use of sysctl to set mtu:
https://anonscm.debian.org/git/collab-
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ifupdown (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
19 matches
Mail list logo
