Re: dhcpcd, carrier and RTM_INFO

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

    Date:        Sun, 05 Feb 2012 13:56:14 -0500
    From:        Greg Troxel <gdt%ir.bbn.com@localhost>
    Message-ID:  <rmihaz52jox.fsf%fnord.ir.bbn.com@localhost>

  | My impression is that historically (as in 2.8BSD, 4.1BSD) IFF_RUNNING
  | meant "resources are allocated" and it has never had anything to do with
  | link state.

Yes, that's exactly what it (IFF_RUNNING) was (and still is on NetBSD).
It is 100% internal, and of no interest to anything other than the driver
that sets it.

  | However, on Linux and I think Solaris, IFF_RUNNING has been repurposed
  | to mean "link is up or there is no way to know link status".

I've been meaning to suggest something like that for ages, not to
redefine IFF_RUNNING exactly, but to move that flag into one of the
less (externally) accessible fields of the interface struct, and
reuse the bit position for an "interface failed" flag - personally I
think that works better than "interface working" as it is very difficult
to promise that, but it is often easy to see that things are not working.

That's essentially the negative of "up or no way to know" (and since it
is just one bit, which meaning is ascribed to 0, and which to 1, is not
really all that important).

I'd give it a new name (not IFF_RUNNING) to avoid confusion, but it is
amazing just how many people assume that IFF_RUNNING has something to do
with the condition of the media (I haven't looked recently, but net-snmp
iused to use IFF_RUNNING for admin up/down and IFF_UP for "working" which
is all hopelessly bogus, but truly amusing for lo0, which has no need of
resources, and so doesn't use IFF_RUNNING at all, leading to net-snmp
diagnising lo0 as administratively down, but operationally up, a state
that really should never exist - and of course, genuinely, doesn't).

kre