half-/full-duplex ethernet and ifconfig

[David Young]

Today I noticed a funny thing about the ethernet media settings that I
can see and choose through 'ifconfig wm0':

supported Ethernet media:
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect

What's the difference between 'media 10baseT' and 'media 10baseT
mediaopt full-duplex' ?

I thought at first that if I did 'ifconfig wm0 media 10baseT' then it
was up to my NIC and its link partner to negotiate the duplex setting.
I.e., that if I don't specify a duplex setting, then the system assumes
that I don't care. I also expected that whichever duplex setting was
negotiated, I could read it out again using 'ifconfig wm0'. So if I set
'ifconfig wm0 media 10baseT', I should see either

media: Ethernet 10baseT (10baseT full-duplex)
status: active

or

media: Ethernet 10baseT (10baseT half-duplex)
status: active

since the kernel defines non-zero flags for both (IFM_HDX, IFM_FDX).
Instead, I see this:

media: Ethernet 10baseT
status: active

Grovelling a bit in the ifconfig(8) code, I see that that
parentheses-less output means the "active" (negotiated) media and the
"current" (selected) media setting are the same: they're both Ethernet
10baseT.

Digging deeper, I find these lines in mii_phy_add_media():

if (sc->mii_capabilities & BMSR_10THDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, 0, sc->mii_inst),
MII_MEDIA_10_T);
PRINT("10baseT");
}
if (sc->mii_capabilities & BMSR_10TFDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, IFM_FDX, sc->mii_inst),
MII_MEDIA_10_T_FDX);
PRINT("10baseT-FDX");
fdx = 1;
}

This tells me that we're using 0, not IFM_HDX, to represent
"half-duplex"---or do I have the wrong interpretation---and there is no
way to select a rate setting independent of a duplex setting.

But hold on a minute, I see some PHY drivers are using both IFM_HDX
IFM_FDX at least to tell what the negotiated media is:

% grep IFM_HDX ../../dev/mii/*
../../dev/mii/atphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/bmtphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/brgphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/etphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rdcphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;

I am having a hard time seeing the design intention here, can someone
help me out?

Dave

[Masanobu SAITOH]

Hi, David.

Post by David Young
Today I noticed a funny thing about the ethernet media settings that I
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
What's the difference between 'media 10baseT' and 'media 10baseT
mediaopt full-duplex' ?
I thought at first that if I did 'ifconfig wm0 media 10baseT' then it
was up to my NIC and its link partner to negotiate the duplex setting.
I.e., that if I don't specify a duplex setting, then the system assumes
that I don't care.

I think if mediaopt full-duplex isn't set, it act as half-duplex
and it really act as I expected.

Post by David Young
I also expected that whichever duplex setting was
negotiated, I could read it out again using 'ifconfig wm0'. So if I set
'ifconfig wm0 media 10baseT', I should see either
media: Ethernet 10baseT (10baseT full-duplex)
status: active
or
media: Ethernet 10baseT (10baseT half-duplex)
status: active
since the kernel defines non-zero flags for both (IFM_HDX, IFM_FDX).
media: Ethernet 10baseT
status: active
Grovelling a bit in the ifconfig(8) code, I see that that
parentheses-less output means the "active" (negotiated) media and the
"current" (selected) media setting are the same: they're both Ethernet
10baseT.
if (sc->mii_capabilities & BMSR_10THDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, 0, sc->mii_inst),
MII_MEDIA_10_T);
PRINT("10baseT");
}
if (sc->mii_capabilities & BMSR_10TFDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, IFM_FDX, sc->mii_inst),
MII_MEDIA_10_T_FDX);
PRINT("10baseT-FDX");
fdx = 1;
}

The BMSR register give us the "capability" of the PHY. The ANAR register
is set from mii_capabilities and argument of SIOCSIFMEDIA.

Post by David Young
This tells me that we're using 0, not IFM_HDX, to represent
"half-duplex"---or do I have the wrong interpretation

In my opinion, IFM_HDX should be removed. If the duplex has a state other
than full-duplex and half-duplex, it's ok to have bot IFM_FDX and IFM_HDX.
If the duplex setting has only two state (i.e. full and half), the best way
is to use only one flag to identify it.

Post by David Young
---and there is no
way to select a rate setting independent of a duplex setting.

Currently, we have no API to specify an advertise setting for auto
negotiation particularly. I think it's useful on some cases.

Post by David Young
But hold on a minute, I see some PHY drivers are using both IFM_HDX
% grep IFM_HDX ../../dev/mii/*
../../dev/mii/atphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/bmtphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/brgphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/etphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rdcphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;
I am having a hard time seeing the design intention here, can someone
help me out?
Dave

[David Laight]

Post by Masanobu SAITOH
Currently, we have no API to specify an advertise setting for auto
negotiation particularly. I think it's useful on some cases.

When I was playing with ethernet PHY/MAC setup many years ago I
basically decided that the best way to 'force' the mode was to
restrict the bits in the ANAR (AutoNegotiate Advertise Reg) rather
than forcing the MAC itself into a specific mode.
That way you are much less likely to get painful duplex mismatches.

The real PITA is that, while you can read the response register,
you can't easily find the actual operating mode (not without
reading implementation specific registers) because the PHY might
be connected to an old hub that only does 10/100 HDX and uses
autodetect (not autonegotiate).
Ifd you aren't very careful you can use the old settings and
get a HDX/FDX mismatch.
I guess this was much more likely 10 years ago, but 10/100 hubs
are still lurking in dev labs (and are often the only thing lurking
unused for a test LAN.

David

[Thor Lancelot Simon]

Post by David Laight

Post by Masanobu SAITOH
Currently, we have no API to specify an advertise setting for auto
negotiation particularly. I think it's useful on some cases.

When I was playing with ethernet PHY/MAC setup many years ago I
basically decided that the best way to 'force' the mode was to
restrict the bits in the ANAR (AutoNegotiate Advertise Reg) rather
than forcing the MAC itself into a specific mode.
That way you are much less likely to get painful duplex mismatches.

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 note that both Apple and most Windows ethernet driver vendors
implement exactly what you suggest above. On a Mac with Apple's Ethernet
drivers there is no way to force the link to a particular speed and duplex;
setting the media and mediaopt settings simply restricts the autonegotiation
as you describe above.

However, to David's original question: if you're going to use the media
and mediaopt settings to control speed/duplex, then yes, you get half-duplex
unless you expressly specify "mediaopt full-duplex". This was the original
design (you can check with Jason) and drivers that do something else are
nonconformant. Changing it at this point will break things for many users,
specifically by causing setups intended to be half-duplex to not be so.

Thor

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

[Mouse]

Post by Thor Lancelot Simon
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.

/~\ 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

[Thor Lancelot Simon]

Post by Mouse

Post by Thor Lancelot Simon
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

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

[Thor Lancelot Simon]

Thor,
switfches with PHY ports where the hardware _does not implement auto-negotiation_., period.

No. When such a switch is the link partner, a correct device driver on the
NetBSD end should do precisely what Apple (and most Windows driver
maintainers) do: when configured for one mode only, attempt to autonegotiate,
offering only that mode, and if autonegotiation fails, forcibly put the
local PHY in that mode -- if even necessary. I have certainly worked with
PHYs which when configured to autonegotiate with only one mode, will
reasonably "fall back" to that mode when autoneg fails; for all I know this
may be the usual behavior.

A driver implementing this behavior will correctly interoperate with a
link partner set to hardwired speed/duplex, as well as one with working
autonegotiation that is turned on. That's not true for the current
implementation. The only case where what I propose won't work is if the
link partner has broken autonegotiation which cannot be switched off,
and I haven't actually run into any link partners like that. There
may be some, but I'd like an example, because if there are, they cannot,
for example, talk to anything running Mac OS X.

Thor

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

[Mouse]

Post by Thor Lancelot Simon
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.

I don't think I have either - if you're talking about just the device's
capabilities - though I am by no means confident such devices don't
exist.

However, the device on the other end is not always under your control,
and getting its admins to turn off autoneg, or let you turn it off, can
be, umm, nontrivial. (Yes, I do work for an ISP, why do you ask?)

Post by Thor Lancelot Simon
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.

This strikes me as an eminently reasonable approach.

/~\ 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

[David Young]

Post by Thor Lancelot Simon
However, to David's original question: if you're going to use the media
and mediaopt settings to control speed/duplex, then yes, you get half-duplex
unless you expressly specify "mediaopt full-duplex". This was the original
design (you can check with Jason) and drivers that do something else are
nonconformant. Changing it at this point will break things for many users,
specifically by causing setups intended to be half-duplex to not be so.

I think that whether anything breaks for anyone depends on what changes
and how. For example, I think it's safe to promote the media selection
'media 10baseT' somewhere in the kernel to 'media 10baseT mediaopt
half-duplex' and to use both IFM_HDX and IFM_FDX consistently inside the
kernel, especially when sending the current/active media *out* of the
kernel.

That still doesn't give us a duplex "don't care" setting, but I cannot
think of a time when I *do* care what bitrate but I *don't* care what
duplex.

Dave

[Matt Thomas]

Post by David Laight
The MAC hardware didn't need to know whether the speed was 10M or 100M
the data just got clocked through the fifos faster.

That is untrue. Most MACs have to be told the negotiated speed.

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

[David Laight]

Post by Matt Thomas

Post by David Laight
The MAC hardware didn't need to know whether the speed was 10M or 100M
the data just got clocked through the fifos faster.

That is untrue. Most MACs have to be told the negotiated speed.

The specific MAC I was using (I think that one was a pcmcia card)
definitely didn't need to know, neither did the 10/100 forms of
the amd lance, nor the sun sbus FEPs (hme?).
Although the latter would receive it's own traffic an 10M, but not 100M.
They all needed to know about FDX.

Of course, none of those are Ge - and Ge might need different MAC
timers.

David

[David Laight]

Post by David Young
That still doesn't give us a duplex "don't care" setting, but I cannot
think of a time when I *do* care what bitrate but I *don't* care what
duplex.

I cared about the HDX/FDX but not about the speed!
The MAC hardware has to be set HDX/FDX matching what the PHY is doing.

The MAC hardware didn't need to know whether the speed was 10M or 100M
the data just got clocked through the fifos faster.

I suspect the only broken autonegotiaton comes about when connected to
devices that don't actually do it - especially after replugging from
a device that does.

Remember the history.
The original 10BaseT spec defined 'link test pulses', one was sent
at a fixed interval to indicate the presence of the system.

When 100BaseT was added, it sent a short burst of link test pulses.
A system receiving the bursts knew it could send at 100M (or 10M).
This is called 'autodetect'.

Many 10/100 autodetect hubs ran two collision domains (one at each
speed) with a bridge between them.

The FDX modes added 'autonegotiation', here the burst of link test
pulses is modified so it can encode a few bytes of data.
An autodetect hub will see this an the 100M link test sequence and
send at 100M (HDX) regardless of the advertised speeds.

Almost all hubs/switches than can to FDX are 'store and forward'
devices. Some of the very early ones were 'cut through' - and
the target port better be idle!

I don't think there was ever any mainstream that did FDX that diddn't
support autonegotiation.

The problem tends to be drivers that use the recieved autonegotiate
(ANRR?) value to detect the mode - and get a stale value when the cable
is replugged into a 10M hub or an 10/100 autonegotiate hub.

The ANAR and ANRR are fixed MII registers, the actual operating mode
of the PHY is only MD.

David

[Bryan Cook]

Dave,

I did a lot of experimenting (and groveling thru code), and here are my
conclusions:
-- If I set only the media, then the mediaopt is assumed to be 0, so it
wipes away everything that was there, including "full-duplex", so the link
Is half-duplex.
-- If "full-duplex" is not displayed for "ifconfig wm0", then the link is
half-duplex.
-- There is no explicit way to set 'half-duplex'. IFM_HDX is not used -
the lack of IFM_FDX is used.

-- For'media', one may set either a "speed" (e.g., 100baseTX), or
'autoselect', but not both.
-- If "autoselect" is not set for media, then there is no autonegotiation.
-- If autoselect is set for media, then the link autonegotiates to its
fullest capability.

Based on the above:
-- 'ifconfig wm0 media 10baseT' - the link is running at 10 mbit,
half-duplex and there is no autonegotiation.
-- 'ifconfig wm0 media 10baseT mediaopt full-duplex' - the link is running
at 10 mbit, full-duplex and there is no autonegotiation.

-- A subsequent 'ifconfig wmo media autoselect' will cause the link to
autonegotiate to 1000baseT and full-duplex.

Post by David Young
Today I noticed a funny thing about the ethernet media settings that I
media none
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
What's the difference between 'media 10baseT' and 'media 10baseT
mediaopt full-duplex' ?
I thought at first that if I did 'ifconfig wm0 media 10baseT' then it
was up to my NIC and its link partner to negotiate the duplex setting.
I.e., that if I don't specify a duplex setting, then the system assumes
that I don't care. I also expected that whichever duplex setting was
negotiated, I could read it out again using 'ifconfig wm0'. So if I set
'ifconfig wm0 media 10baseT', I should see either
media: Ethernet 10baseT (10baseT full-duplex)
status: active
or
media: Ethernet 10baseT (10baseT half-duplex)
status: active
since the kernel defines non-zero flags for both (IFM_HDX, IFM_FDX).
media: Ethernet 10baseT
status: active
Grovelling a bit in the ifconfig(8) code, I see that that
parentheses-less output means the "active" (negotiated) media and the
"current" (selected) media setting are the same: they're both Ethernet
10baseT.
if (sc->mii_capabilities & BMSR_10THDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, 0, sc->mii_inst),
MII_MEDIA_10_T);
PRINT("10baseT");
}
if (sc->mii_capabilities & BMSR_10TFDX) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, IFM_FDX,
sc->mii_inst),
MII_MEDIA_10_T_FDX);
PRINT("10baseT-FDX");
fdx = 1;
}
This tells me that we're using 0, not IFM_HDX, to represent
"half-duplex"---or do I have the wrong interpretation---and there is no
way to select a rate setting independent of a duplex setting.
But hold on a minute, I see some PHY drivers are using both IFM_HDX
% grep IFM_HDX ../../dev/mii/*
../../dev/mii/atphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/bmtphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/brgphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/etphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rdcphy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;
../../dev/mii/rgephy.c: mii->mii_media_active |= IFM_HDX;
I am having a hard time seeing the design intention here, can someone
help me out?
Dave
--
David Young

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