Re: ipunblock branch testing

[Dan Williams <dcbw redhat com>]

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