Re: ipunblock branch testing
- From: Dan Williams <dcbw redhat com>
- To: Tore Anderson <tore fud no>
- Cc: networkmanager-list <networkmanager-list gnome org>
- Subject: Re: ipunblock branch testing
- Date: Wed, 02 Nov 2011 20:24:03 -0500
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: <warn> Failed to add route Netlink Error (errno = No route to host)
> NetworkManager: <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: 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: <warn> Failed to add route Netlink Error (errno = File exists)
> NetworkManager: <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.
] [Thread Prev