DHCPv6 *still* broken for F17 alpha

[Dan Williams]

On Thu, 2012-03-15 at 10:07 +0000, Petr Pisar wrote:
> On 2012-03-14, Dan Williams <dcbw at redhat.com> wrote:
> > On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
> >> * Dan Williams
> >> 
> >> > 0.9.4 snapshots do not require both methods to complete (with either
> >> > success or failure) before saying the machine is connected.  Thus if
> >> > IPv4 completes first, NM will say it's connected, and continue IPv6 in
> >> > the background.  And vice versa.
> >> 
> >> That is true, however, if IPv6 completes first, and IPv4 (still running
> >> in the background) eventually ends up failing, the *entire connection*
> >> will be torn down - including the perfectly working IPv6 connectivity.
> >> So the successfully connected state only lasts for about 20 seconds.
> >> 
> >> A trivial patch that fixes this problem is attached, please apply.
> >
> > I've gone back and forth on this last week; since it changes the
> > default, it would break the case where somebody depends on the current
> > behavior, ie that by default IPv4 may not fail.  After this patch is
> > applied, a network where IPv6 connectivity is available but broken (or
> > where the router sends RAs with private prefixes like fdxx::) and IPv4
> > is for some reason also broken, will make NM show "connected" when in
> > fact we aren't really.  The new connectivity detection will help that
> > somewhat, but we haven't enabled it by default yet for a few reasons.
> >
> How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope
> address in IPv4 is Ok, while getting such address in IPv6 is considered
> as failure?
> 
> Unfortunatelly companies expect deploying NAT66 (network multihoming
> while missing access to BGP).
> 
> Also user may expect installation from local mirror or through proxy.
> 
> I think you are doing the installer to much smart resulting in crappy
> behaviour in special cases.
> 
> If you want to check connectivy, let's ping official Fedora mirror.
> Present the ping result to user as a hint, but do not prevent him from
> proceding.

The current connectivity checking code is built-but-inactive in F17, you
can enable it by adding these entries
to /etc/NetworkManager/NetworkManager.conf:

[connectivity]
uri=http://<url>
interval=120

the URL is expected to return one or both of:

1) an HTTP header named "X-NetworkManager-Status" with the value of
"online"
2) an document body consisting only of the text "NetworkManager is
online" (can be customized by an option in the config file)

This method lets NM (in the future) detect captive portals and will
allow auto-login in those networks.  It's basically what Windows does
for its connectivity detection too.  If we have proxy information, in
the near future we'd use it here as well.  If NM doesn't get the correct
response then for the most part, we can't consider the machine to have
Internet connectivity.  Obviously this can be disabled (by not
specifying a connectivity check URI) for cases where it's known not to
work.

The only effect this checking will have is to change NetworkManager's
state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL.  It
doesn't do anything odd like disconnect and retry some other connection,
which wouldn't make much sense.  It just changes some state which apps
can use to figure out whether they'd connect to say your IRC server or
your email or whatever automatically.

Dan