Subject: Full duplex media type [was: Re: Implementing interface media type autodetection?]
To: Matt Thomas <>
From: Jonathan Stone <>
List: tech-net
Date: 06/11/1996 17:51:30
Matt Thomas writes:

>Full Duplex is completely orthogonal to IFF_SIMPLEX.  I'm talking about
>full-duplex at the physical level.  10baseT full duplex (ie. suppress
>collision circuitry and run rx/tx at the time).

And also for 100baseT.  In fact, I think there's quite a lot that
NetBSD (or *any* unixoid system, for that matter) could do better

Although the final standardised IEEE 100baseT spec includes
auto-negotiation of full-duplex -as an extension to that part of the
10baseT protcol re-defined for negotiating 100baseT -- there is at
least one popular card, supported by NetBSD, which *does* support
full-duplex in hardware but *doesn't* support the 100baseT full-duplex
negotiation protocol.

I'd hope NetBSD would provide a mechanism to support a user-space
enable/disable of full-duplex for such hardware -- which would
override whatever the autonegotiation decided..  Turning *off*
IFF_SIMPLEX _could_ be a mechanism to do that, if IFF_SIMPLEX is the
default for ethernet devices; but the kernel would need to pass a
change of IFF_SIMPLEX all the way down to the driver, and have the
driver Do The Right Thing.  Last time I looked, drivers didn't do

I also beleive that, for interfaces that *can* auto-negotiate
full-duplex, there can be a good case for disabling such
autonegotiation, in addition to providing a way for the superuser to
directly frob the card's full-duplex vs. half-duplex state.  (IMHO,
this should be separate from media type autodetection, since AFAIK it
aapplies only to switched (or point-to-point) ieee 802 links, on which
both ends of the pt-to-pt link agree on full-duplex.

I don't see how IFF_DUPLEX can perform both those roles.

In fact, I think there's another issue that makes things actually  worse.
Some 100baseT cards are also quite pig-headed about when they do
auto-sense (as in, one has to boot  DOS, run the diagnostic software,
and tell the card "auto-sense" before they auto-sense properly, at
which point the auto-sensed speed is saved in non-volatile storage on
the card. NetBSD's "autosensing" seems to just retrieve the
non-volatile value.

(I' no longer have access to a full-duplex 100Mbit switch with a spare
port to definitely verify all this, but it's definitely been A Real
Pain in the past.)

Then again, maybe it's just me who's run into this due to the
combination of PCI 100Mbit ethernet cards, hubs, and switches I've
been using.  Who else has experiences, either good or bad, with for-real
100Mbit networks, either full-duplex or half-duplex?