dhcpcd, carrier and RTM_INFO

[Roy Marples]

Hi List

The recent dhcpcd in -current has "better" carrier handling.
Essentially it obeys each RTM_INFO message and respects the interface
flags given.
The reasoning for this is because when the OS wakes a sleep state it
flags the interface as down and then up immediately if it has a valid
link.
The new dhcpcd behaviour sees this and now works correctly by
re-negotiating it's lease.

However, some drivers are not setting IFF_RUNNING in ifm_flags which
causes dhcpcd to think the carrier is actually down when it's actually
up.
The old behaviour was to check the interface flags in a subsequent
SIOCGIFFLAGS call, which breaks the wake up case described above.

So my question is this - is the lack of IFF_RUNNING a driver bug or
expected behaviour and I would re-work dhcpcd for this?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Roy Marples
The recent dhcpcd in -current has "better" carrier
handling. Essentially it obeys each RTM_INFO message and respects the
interface flags given.
The reasoning for this is because when the OS wakes a sleep state it
flags the interface as down and then up immediately if it has a valid
link.
The new dhcpcd behaviour sees this and now works correctly by
re-negotiating it's lease.
However, some drivers are not setting IFF_RUNNING in ifm_flags which
causes dhcpcd to think the carrier is actually down when it's actually
up.
The old behaviour was to check the interface flags in a subsequent
SIOCGIFFLAGS call, which breaks the wake up case described above.
So my question is this - is the lack of IFF_RUNNING a driver bug or
expected behaviour and I would re-work dhcpcd for this?

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. Paying attention to IFM_ACTIVE (and ignoring IFF_RUNNING)
seems like the right thing.

Interface up and down and valid link are separate issues; I don't see
how they should be commingled.

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".

[Roy Marples]

Post by Greg Troxel
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. Paying attention to IFM_ACTIVE (and ignoring
IFF_RUNNING)
seems like the right thing.

That's good to know.
I've adjusted dhcpcd in my git tree accordingly.

Post by Greg Troxel
Interface up and down and valid link are separate issues; I don't see
how they should be commingled.

Well, a valid link but with the interface marked as down I treat it as
carrier down in dhcpcd because things like the hardware address can then
be changed which affects the lease.
When it's marked as up it re-negotiates it.

Post by Greg Troxel
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".

Yes.
As part of the IPv6 RA work I added checks for IFF_RUNNING on the Linux
netlink code dhcpcd uses so it's actually checked anyway which makes the
proposed change above fine.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Roy Marples

Post by Greg Troxel
Interface up and down and valid link are separate issues; I don't see
how they should be commingled.

Well, a valid link but with the interface marked as down I treat it as
carrier down in dhcpcd because things like the hardware address can
then be changed which affects the lease.
When it's marked as up it re-negotiates it.

Certainly if an interface is down that's important, and I didn't mean
you should ignore it. I just meant that an interface is up if something
has done "ifconfig foo0 up" (or implicitly via assigning an address).
An interface that is administratively down (no IFF_UP flag) means that
the operator/etc. has asked that it not do anything, so if you find no
IFF_UP but positive carrier status that sounds like a bug (in the
driver). But maybe I'm confused and down interfaces report carrier but
do nothing else. Still, without IFF_UP I would ignore the interface.

On a 5.1 system with ex0, I find that the ifconfig 'status: active' line
goes away when the interface is down, and after ifconfig up it's briefly
status: no carrier followed by status: active.

With dhclient (sorry, I have not yet made the effort to move over to
your code on the one NetBSD machine I run a dhcp client on), I think
there's the notion of the interface being set to UP when dhclient starts
on it.

All that said, your strategy of triggering renegotiation when anything
interesting might have happened sounds entirely sensible.

[Mouse]

Post by Greg Troxel
An interface that is administratively down (no IFF_UP flag) means
that the operator/etc. has asked that it not do anything, so if you
find no IFF_UP but positive carrier status that sounds like a bug (in
the driver).

Then I suspect we have lots of buggy Ethernet drivers. Certainly my
experience and expectation is that the driver's reporting of media
sense (link, speed, duplex, etc) is orthogonal to IFF_UP (though some
interfaces have to be brought up at least once for media sensing to
work, even if they're later brought down again). I also think that's
the most useful way, too, in that it makes available information which
is not available under the scheme you outline.

Post by Greg Troxel
But maybe I'm confused and down interfaces report carrier but do
nothing else.

Yeah, that.

Post by Greg Troxel
Still, without IFF_UP I would ignore the interface.

Agreed, no question there.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

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

| 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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de