Re: half-/full-duplex ethernet and ifconfig

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Wed, Nov 14, 2012 at 11:17:59AM -0500, Mouse wrote:
> > Yes.  I firmly believe that allowing "hardwired" setting of duplex
> > and speed is insane.  If it ever solves a problem, the problem should
> > be solved at the other end of the link, instead.
> 
> I have seen cases where NetBSD's taking this stance would simply render
> it useless, even if it is abstractly correct.  There are cases where it
> is important to interoperate with a particular device, even if it is
> broken, and broken autoneg, while less common than it once was, is
> hardly unheard of.

I've heard this argument before.  I don't agree.  Here is why.

You're positing a device at the other end which has broken autonegotiation
*that cannot be turned off*.  I haven't actually seen a device like that.
And I've seen a lot of network devices.

Remember, if you restrict the set of modes on the PHY at the NetBSD end,
if properly implemented drivers will not use any other mode *whether they
manage to autonegotiate or not*.

So, if you have a device with broken autonegotiation, you do not need to
turn off autonegotiation on the NetBSD end; you can turn it off on that
device's end instead.  If NetBSD is made to behave like OS X and Windows
in this regard, then even if configured to always try to autonegotiate,
will not somehow agree to a mode other than the one you told it to try to
negotiate for, even if autonegotiation fails.

Now, I didn't win this argument at Coyote Point and I don't expect to
necessarily win it here.  What we did there was to implement a "force"
bit that reverted to the current behavior.  So if you select
media 100baseTX -- only -- and don't specify "force" it does what everyone
else sane does, and restricts autonegotiation to 100baseTX only; if you do
say "force", it forces the PHY to 100baseTX and refuses to negotiate about
it.

I think that is a nasty hack that is not actually justified by real world
behavior of link partners but it's one I would not oppose for inclusion
in NetBSD if others think it is needed.

Thor