Re: Retiring dhclient

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 16 Nov 2011 16:04:32 +0800
    From:        Ted Lemon <mellon%fugue.com@localhost>
    Message-ID:  <A12A1A32-ED6A-4FF1-A211-52D535E9A996%fugue.com@localhost>

  | The problem, Robert, is that I think only in your mind is this a
  | simple problem for the average case.

No, not simple, or it would be done already and we wouldn't be
discussing it, but tractable.

  | This is precisely what a good network configuration agent is supposed
  | to do for you,

Yes, but lacking that, which your phone apparently doesn't have, and which
NetBSD currently doesn't have, wouldn't a better alternative to nothing be
a sane config that you could set once, when you did work it out, and would
then just do the right thing every later time that you connect?

That's the kind of "first step" config agent that I'd hope to see.

  | and I do not agree with you that this is a problem that need not be solved.

If that is what I said, I don't agree with me either - but I don't think
I said that.   What I said was that it is not a problem that the NetBSD
project needs to solve today (in general).

  | I also don't agree with you that the problem is prohibitively difficult.

Well...  (aside from what is "prohibitively difficult" to one engineer
is just plain hard to another, and child's play to someone else...)

  | IMHO it's pretty easy: you just try a reasonable collection of starting
  | permutations

Which come from?  And reasonable according to whom?

  | and use the one that connects and authenticates successfully,

And here's the rub - connects and authenticates to what exactly?  To
your hotel network?   No thanks, that's not useful to me, I want
internet connectivity, plus intra-org connectivity, but how do we test
that either of those works?   Is being able to connect to google.com
the test?   Not for me, I don't much care, being able to connect to
netbsd.org would be more useful (for me, but perhaps not others), and
of course, the root nameservers (for me).  On the other hand, the vast
majority of the world (even of netbsd users) don't care about netbsd.org
(most of the time) or root nameservers, ever.   Working out "it is working"
is a truly hard thing to do - especially when you consider all the possible
failure cases, some of which still indicate that the local connectivity is
good, and correctly configured, and something else is broken, out of our
control, and others don't.

  | discarding the rest.   This is what Google Chrome does by default
  | today for the dual-stack scenario;

Dealing with just dual stack is comparatively trivial.

  | extending this to the multiple interface scenario is trivial.

No, it isn't - consider a trivial case when (say) at the IETF,
on that hotel network (which I presume is WiFi, and so generally
to be preferred over the more expensive, and slower, 3G) decides
to implement an IPv6 google.com of their own - you connect to it
you get answers, just not the ones you hoped.  Given that people
there are clever, they even have nameservers sending out apparently
correct dnssec secured IPv6 addresses for google.com - but with
access to the root servers filtered out, so you can't actually get
the certificates to verify.

Doing all this, truly properly, really is hard.

On the other hand, the method you described isn't too much away from
what I'd expect as a first, or second, step to a solution - an algorithm
that works for most people, most of the time, and some config that you
can set to tell it when it failed, so it doesn't repeat the same
mistake the next time - and leave the harder part of automatically
determining failure, and then automatically responding, for a future
revision, once we better understand how to do that.   ("failure"
here is algorithm failure, not just connection failure.)

kre