Roy Marples <roy%marples.name@localhost> writes: > 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".
Attachment:
pgptFtHTypdaa.pgp
Description: PGP signature