Re: ipunblock branch testing

[Dan Williams <dcbw redhat com>]

On Thu, 2011-11-03 at 17:27 +0100, Tore Anderson wrote:
> * Dan Williams
> 
> >> The behaviour I would expect instead, is that ticking the «Require» box
> >> for an address family would block NM from succeeding the overall
> >> connection until the required address family had completed. If both
> >> address families was ticked as required, then it should not have
> >> reported an overall success until they both had completed.
> > 
> > I suppose we could make that happen; it shouldn't be too hard to do so
> > in the code.
> 
> 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?

> > Hmm, I thought your original note was about *always* doing DHCPv6 in
> > parallel with SLAAC no matter what, even if the M/O bits weren't set.
> > I've seen in recent RFCs that the M/O bits are pretty much deprecated so
> > maybe they aren't intended to mean much anymore.  But I didn't
> > intentionally change behavior here, so perhaps we should revisit that.
> > Or maybe I'm not remembering your patch correctly?
> 
> I'm not aware of any RFC deprecating the M/O flags, could you point me
> to it? As far as I know, their meaning is still the same:

I lied, it was a while ago when investigating some other stuff I
couldn't find any mention of M/O in the RFC I was reading.  But
apparently I wasn't reading RFC 5175/4861 which does talk about M/O
flags.  So nevermind about this.

> * M flag means to ask DHCPv6 for addresses and other config (e.g. DNS)
> * O flag means to ask DHCPv6 for other config *only* (e.g. DNS). O flag
>   is ignored/meaningless if M=1.
> 
> The M/O flags and any Prefix Information Options are completely
> orthogonal, i.e., if M=1 and there's a PIO with Autonomous=1, that means
> *both* SLAAC and stateful DHCPv6 should be performed and at least two
> addresses should end up being configured on the interface. In other
> words, M=1 does *not* cancel Autonomous=1 in a PIO - this is the thing
> my patch fixed. It is described in more detail in the commit message, see:
> 
> http://mail.gnome.org/archives/networkmanager-list/2011-August/msg00247.html
> 
> However, I'm not seeing this issue any longer with the ipunblock branch,
> so maybe the patch is no longer necessary?

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.

So I guess immediately when we receive the M/O flags (via RTM_NEWLINK)
we should kick off DHCP, 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.  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?  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?

Dan

> >> If you're interested in debugging these more, I'll be happy to provide
> >> full debug-level logs + PCAPs.
> 
> Attached!
> 
> Best regards,