Re: ipunblock branch testing

* 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, 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:

* 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:

However, I'm not seeing this issue any longer with the ipunblock branch,
so maybe the patch is no longer necessary?

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


Best regards,
Tore Anderson

Attachment: ipv6-init.pcap.gz
Description: GNU Zip compressed data

Attachment: messages.gz
Description: GNU Zip compressed data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]