Kacheong Poon writes:
> > In other words, if you're using BOOTP, DHCP, or RARP to acquire
> > interface addresses, you may have to wait "forever" for this event to
> > occur. "Forever" is almost certainly too long for anyone's patience
> > to hold out.
>
>
> Correct. This means that those services which depend on
> milestone/network will not be started in this "waiting
> period." The standalone profile will be used in the mean
> time.
Perhaps I'm lost here, but I thought that milestone/single-user
depends on milestone/network. Hence, if one of those things is
waiting for a long time, the system just plain hangs. There's little
useful work that can be done here.
I'm still uncomfortable with having SMF states that can hang waiting
on activity that's outside of the local system. It makes some sense
in some very narrow cases (e.g., no sense proceeding if you can't
mount /usr because it's on a SAN and the interfaces for the SAN aren't
running), but seems incorrect in general.
> > Similar things occur if we have to wait on indeterminate behaviors in
> > the lower layers, such as 802.1X or 802.11 AP interactions. There's
> > just no telling when or if those will ever converge, and that's not
> > necessarily a bug.
> >
> > So, I would assert that either the time is ripe to open sockets when
> > time begins (which is when the ip module itself is loaded and 'lo0'
> > logically becomes available), or that there just is no such time that
> > can be reliably determined for all systems.
>
>
> I guess the question is not about whether a time can be
> determined such that there is external IP connectivity, as
> we can certainly determine such time.
Really? I'm not so sure of that.
> The question is
> whether this time is useful or not. The argument is that the
> network connectivity can come and go at any given time. So
> what is the point of finding the very first time? And to
> make things worse, the connectivity can be flaky such that
> the system are bouncing between connected and not-connected
> states. To make thing even worst, what outside IP connectivity
> really means is not clear. For example, the machine may be
> able to contact other hosts in the same sub network but not
> outside that. Does it mean that it has "limited connectivity?"
> In summary, it is not that useful to have such milestone.
Yes, exactly.
> > Backing up to the original problem: what actually does depend on
> > milestone/network _and_ also needs to have some non-lo0 interface
> > plumbed? Are any of these dependencies not bugs?
>
>
> No, I don't believe the intention of milestone/network is
> about plumbing interface. It is about outside IP connectivity.
OK, then, "plumbed and somehow configured."
> Have I summarized the argument against this milestone above
> correctly? So the question is about what services depend on
> outside IP connectivity before they should be started.
Yes.
> I
> suppose there are at least a couple, such as xntpd.
Nope. xntpd works fine with attached local clocks.
> > If any of them are not actually bugs or design flaws in those
> > services, then I'd like to understand how that's the case.
>
>
> I don't think it is a bug for xntpd to depend on external IP
> connectivity before it should be started.
I do.
> > In order to talk with the outside world safely, IPsec and IP Filter
> > both need to be initialized.
>
>
> We've discussed this. I guess milestone/network needs to
> depend on the above.
Agreed.
> > That makes them rather different from configuring interfaces, unless
> > "configuring" doesn't actually mean waiting for the interfaces to
> > become usable.
>
>
> I think the key problem with milestone/network is whether
> or not it is useful because connectivity can come and go,
> and the meaning of connectivity is not that clear. I suspect
> that for most customers, connectivity really means that a
> machine can contact hosts in the same sub network.
You know this precisely when you receive packets from those nodes that
are in response to packets you've sent. You don't know it at any
other time.
> If there
> is a problem contacting hosts outside that, most customers will
> consider that as a network problem, such as the router is
> not functioning. And I believe NWAM can determine this simple
> situation. For flaky connectivity, I again suspect that it
> is not a common case such that NWAM can detect that and inform
> the user.
I think diagnosis of networking faults is a separate topic from the
matter of configuring and using network interfaces.
It's certainly no less important -- I'd even argue that it may be more
important -- but I'm not sure that it's something that NWAM is in a
position to solve.
Consider the typical sorts of user problems:
- User forced Ethernet duplex to "full," which causes the switch to
go (per the standards!) into "half," and causes lousy performance.
- User has /etc/nsswitch.conf and/or /etc/resolv.conf misconfigured,
so that "ping -n" works and nothing else does.
- User needs to have some routes, but doesn't know how to make the
system add them. User can reach some hosts, but not others.
- User should have DHCP enabled, but can't figure out how, or needs
to turn it off, and can't.
These are encountered time and again on just about every forum I watch
where users can post. The last of those is something that NWAM should
resolve, and the middle two might be made rarer by NWAM, but I don't
think that all of them are completely avoided, nor do I see now NWAM
makes diagnosis of the problem easier.
> I guess the basic question is whether external IP connectivity
> is a useful state of the machine such that we need to make it
> a milestone for other network services to depend on, both for
> backward compatibility and for future usage. Comment?
Given that it's something that I don't think we can in fact assert to
be true, I don't think we should have such a state.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
