Re: ipunblock branch testing

[Tore Anderson <tore fud no>]

* Dan Williams

>> Great! Just to clarify, though, it would be good if the
>> configuration/addressing for the non-failing address family is still
>> committed as soon as it's available, I'm only referring to the overall
>> "connected" state (i.e., the little popup from the systray applet saying
>> you're connected and so on) that should be blocked from happening until
>> all required address families has succeeded.
> 
> Hmm, if apps aren't supposed to do anything until we're connected, how
> would committing the the addressing before saying connected be useful
> here?

Well, assuming the required address families work fine most of the time,
it means that the fastest one to complete will be ready for use as soon
as possible (by non-NM-integrating applications at least), and then be
joined by the slower one later.

The main issue I see with the current ipunblock branch behaviour is that
it gets NM stuck in a seemingly endless loop of successful activations
and failures if the required one is failing.

Also, RA-based addresses and routing will always be committed instantly
so doing so for the rest of the configuration too makes the behaviour
consistent.

> By accident perhaps, there's still comments in the code talking about
> managed being DHCP only.  One problem is that there's good way to line
> up the PIO with the M/O flags.  The kernel sends out the RTM_NEWLINK
> first with the M/O flags, and then at some later point sends out the
> RTM_NEWPREFIX.  Yes, these are sent in the same function in the kernel,
> but essentially that means there is no positive indication of *lack* of
> a prefix.

I see.

> So I guess immediately when we receive the M/O flags (via RTM_NEWLINK)
> we should kick off DHCP, 

Makes sense, yes.

> and if we get a PIO (via RTM_NEWPREFIX) then great, we handle it,
> otherwise after a period of time if M=0 we fail the  device since you
> need *something* to give you an address or prefix.

Yep, at least if you consider having an address a hard requirement for a
successful device activation. Some musings on that below.

> If no PIO is received but M=1 then we're fine, we use whatever DHCP gave
> us.  So a table like this:
> 
>           no PIO or A=0 | A=1
>         -----------------------------
> M=0 O=0 | fail          | PIO only
> M=0 O=1 | fail          | PIO + DHCP (non-address)
> M=1 O=x | DHCP only     | PIO + DHCP (address + non-address)
>   
> is that what you'd expect?

Yes, except I'm a bit unsure what is the proper behaviour with M=0 O=x
!PIO/A=0. In this case, you won't get an address, but you may get other
configuration. In some weird corner cases, that might even make some
sense (think for example an isolated LAN using only link-local
addressing where the RDNSS Option and/or Information-Only DHCPv6 are
used for communicating DNS servers, HTTP proxy servers, or whatever).

Question is, if the network administrator has explicitly configured a
router to transmit RAs that explicitly say that there's no global
addresses to be had, is that a failure? Or is it a success, considering
that we are in fact configuring the network connectivity exactly as
prescribed by the network? I don't have a good answer...

> The failure cases for A=1 would be:
> 
> A=1 M=0 O=1 | PIO + DHCP (non-address)| fail if DHCP fails and no RDNSS
> A=1 M=1 O=x | PIO + DHCP (address)    | fail if DHCP fails
> 
> or maybe if DHCP is requested at all, we should fail if it fails?

I am not sure, to be honest. I think you need to decide what should
constitute a «success» first. Is it >=1 global address and >=1 DNS
server? If so, the failure cases above makes sense. If it is
«implementation of what the network told us to», it should fail if O/M=1
and DHCP fails. But if so, M=0 + !PIO/A=0 should also eligible to be
considered a success...

What happens in IPv4 if the DHCP server doesn't advertise any DNS
server, by the way? If that's a fail, then probably that should be the
case in IPv6 too? Same goes for a lack of a default router, maybe?

(BTW my possibly obsolete SLAAC/DHCPv6 patch does make NM consider M=0 +
!PIO/A=0 a success since it lowers the initial target state of the
device to got-ra.)

-- 
Tore Anderson