* 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: 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? >> If you're interested in debugging these more, I'll be happy to provide >> full debug-level logs + PCAPs. Attached! Best regards, -- Tore Anderson
Attachment:
ipv6-init.pcap.gz
Description: GNU Zip compressed data
Attachment:
messages.gz
Description: GNU Zip compressed data