On Wed, 2011-11-02 at 23:36 +0100, Tore Anderson wrote: > * Dan Williams > > > Finally got everything set up to test this, found the problem, fixed it, > > and tested it and a few other configs. Give it one more shot and let me > > know how it works for you? > > Seems much better, thanks! It connects fine with both IPv4 and IPv6 > modes Auto: When both work and IPv4 is the faster one, when both work > and IPv6 is the faster one, when only IPv4 works (no RAs), when only > IPv4 works (RAs but unresponsive DHCPv6 server), and when only IPv6 > works (unresponsive DHCPv4). > > The only thing I feel is a bit odd, is the behaviour when «Require > IPv(4|6) for this connection to complete» is set. If it is, and the > address family in question doesn't work, then it will first succeed the > overall connection only to fail it again shortly after, when the > activation attempt times out. > > 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. > Another thing I noticed that it successfully connects to my network with > both stateful DHCPv6 and SLAAC on the first attempt every time, which > means my patch about DHCPv6/SLAAC interaction might no longer be > necessary. Is that intentional? 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've also noticed a few error messages in the logs (normal log levels): > > NetworkManager[7362]: <warn> Failed to add route Netlink Error (errno = No > route to host) > NetworkManager[7362]: <warn> Failed to add route Netlink Error (errno = > Invalid argument) I've seen these too; still need to track them down. I believe they're still fallout from the libnl fixups that happened a while ago. > NetworkManager[7362]: merge_ip6_configs: assertion `src != NULL' failed This one is interesting. Debug logs from this happened would be good; I can't think of why this should occur, and that's why we put the g_return_val_if_fail() stuff in there :) > NetworkManager[7362]: <warn> Failed to add route Netlink Error (errno = File > exists) > NetworkManager[7362]: <error> [1320272846.119370] [nm-system.c:1061] > nm_system_replace_default_ip6_route(): (eth0): failed to set IPv6 default > route: -1 More libnl fixups I imagine. Debug logs would be good. > If you're interested in debugging these more, I'll be happy to provide > full debug-level logs + PCAPs. Thanks! Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
