SEO

> I've been digging around in the code a bit more and am convinced now
> that LINK_STATE_UNKNOWN can't be relied upon.

Agreed. As it's name implies, the state is UNKNOWN and hence there should be
no guarantee that we can communicate using the interface. In some cases this
isn't necessarily a problem (bgpd(8) perhaps?), however for trunk(4) an
interface being in an unknown state shouldn't imply that it is active (IMHO).

> For example, em(4) will report a link state of unknown when started
> without a cable plugged in, only after plugging and unplugging I get
> a LINK_STATE_DOWN.

That's interesting...

> But even if it correctly indicated it as down from
> the beginning, the problem would still remain with the ones which are
> not reporting a state at all.

Correct.

> Not sure about the way forward now. Will read more, hoping to get an
> idea.

I think we're probably dealing with three classes of interfaces/drivers:

1. Those that cannot report link state (mainly old hardware?)
2. Those that report link state
3. Wireless interfaces

For (2) there are no issues. For (3) I think it is a case of either having
them report as UP either once associated, or once the radio is active and the
device is configured to be able to associate (as per my previous email). For
(1) there is no easy solution other than to change trunk to once again use !=
LINK_STATE_DOWN, or trunk is simply not supported with these devices (makes
more sense to me, at least for failover mode).
--
----------------------------------------------------------------------------
=> Joel Sing | joel@ionix.com.au | 0419 577 603 <=
----------------------------------------------------------------------------

"Real stupidity beats artificial intelligence every time."
- Terry Pratchett, Hogfather