modprobe -Q is not 'silent enough' / ifup is too picky about return status.

this patch removes the 'modprobe -Q ipv6' action from ifupdown, and updates the default gateway to 2000::/3 from ::/0

There is the same problem in Jaunty - ipv6 is compiled into kernel ( no module ) and ifup fails on modprobe -Q

There are two distinct changes in the patch attached in the previous comments. The first removes the modprobes for ipv6, the second changes the default route specifier.

Taking the second one first, it is not at all clear that this is the right thing to do? Also though IANA is only giving out addresses in this range the documentation does seem to imply addresses outside this range could be valid:

  [3] The IPv6 Unicast space encompasses the entire IPv6 address range
       with the exception of FF00::/8. [RFC4291] IANA unicast address
       assignments are currently limited to the IPv6 unicast address
       range of 2000::/3. IANA assignments from this block are registered
       in the IANA registry: iana-ipv6-unicast-address-assignments.

The first part I can reproduce here on Jaunty (see below). Probabally the right thing to do is not remove the probes but ignore any errors from them so that if someone builds their own kernel with the support back as modules things will still work:

# ifup -v eth0
Configuring interface eth0=eth0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/dhclient3-apparmor
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant

ifconfig eth0 10.0.0.10 netmask 255.255.255.0 up
 route add default gw 10.0.0.1 metric 100 eth0
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/postfix
run-parts: executing /etc/network/if-up.d/wpasupplicant
Configuring interface eth0=eth0 (inet6)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/dhclient3-apparmor
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
modprobe -Q ipv6
Failed to bring up eth0.
#

Hmm, I'm inclined to agree. Still, this draws my attention to the module loading behaviour of modprobe and its method of automatically loading modules as required:

alias net-pf-10 ipv6

... shouldn't this happen if/when the kernel attempts to register any address of this family, or route for that matter?

I don't use the aliases file much at all, I simply don't trust it, meaning I'm unfamiliar with how it works internally or how that would impact ifup/ifdown. Being old school, I hand-type the modules I use into /etc/modules, but even this would alleviate the problem.

In short, ===I don't see how module loading is any responsibility of ifup/ifdown to begin with===. Even PPP connections load the ppp module as required simply by executing pppd in any modern Linux environment.

That said, I don't particularly care which method is employed, as long as I can stop hand-patching each and every ifupdown installation on my network.

On the other hand, ===modprobe -Q should NEVER set a failure status=== as I understand it:

       -Q --silent
                 As -q with the addition that all warnings and errors are also
                 silenced.

This doesn't state that it must return a True value, but I think for the case of rapid or inconsequential execution, this fact seems implied to me. What we have here is two problems compounding to produce a strange (and inconvenient) result, but in my opinion they should both be fixed.

--

In respect to the default route designation, I don't see how this is required in a modern environment. Router advertisements should distribute next-hop routes automatically. In an environment where this isn't the case, either route designations should work with appropriate metrics.

The reason I changed the ::/0 to 2000::/3 in the patch was because ... well, metrics. fe80::/8 is within the realm of ::/0 if the route metric of ::/0 is set incorrectly. The route command doesn't provide any method of manually setting a metric, so we take its word for it that it is correct. Not ALL implementations do this properly, which results in broken anycast routing, hence breaking router adverts and so on.

I haven't seen this happen since one instance of Debian years ago, so ===it's probably a null issue at this point and that modification can be removed===. Still, I can't see any situation where it would break anything, except perhaps an otherwise operational (but broken by design) IPv6 network.

@Nautilus -- I would tend to agree but as Jaunty is past feature freeze all places this could be considered for are now in 'minimum changes' mode. So although just removing it should be safe across the board, this is guarenteed safer and more likely to be accepted. As for the route change, again least changes is easiest to get in.

Ok have put together a debdiff based on the original diagnosis. It basically ignores the exit from the modprobe as that should work reasonably well with and without ipv6 builtin to the kernel.

I have built and tested .debs from this and they seem to work.

@Sponsors -- looking to get the update to ifupdown in the debdiff on the previous comment (http://launchpadlibrarian.net/23195609/ifupdown-handle-ipv6-builtin) uploaded for Jaunty. Let me know if I need to do anything additional.

Note that the next upload of modprobe removes -Q entirely

So you might want to take that into account with your upload ;)

@Scott -- thanks for the heads up. Following our irc conversation here is an updated debdiff which incorporates the additional changes you suggested. I have changelogged these are three separate semantic changes:

  * modprobe failures for ipv6 are benign as the module is likely built-in.
    (LP: #107432)
  * modprobe -Q is now deprecated and going away, move to using -q.
  * modprobe for ipv6 should honour the blacklists.

@Scott -- hopefully a final version with all of the generated files updated as after a binary build.

This bug was fixed in the package ifupdown - 0.6.8ubuntu16

---------------
ifupdown (0.6.8ubuntu16) jaunty; urgency=low

  * modprobe failures for ipv6 are benign as the module is likely built-in.
    (LP: #107432)
  * modprobe -Q is now deprecated and going away, move to using -q.
  * modprobe for ipv6 should honour the blacklists.
  * update all generated files to match their source versions (*.defn,
    main.c).

 -- Andy Whitcroft <email address hidden> Thu, 05 Mar 2009 13:47:48 +0000