> James Carlson wrote: >> Steven Stallion writes: >> >>> Garrett D'Amore wrote: >>> >>>> en_xxx set the bits used in 802.3u (MII) configuration. Directly >>>> setting the duplex and speed properties would be a subset of >>>> functionality. (Because using the en_xxx bits, you can offer to >>>> support >>>> more than a single configuration ... e.g. you could offer to support >>>> 100 >>>> FDX *and* 10 FDX.) >>>> >>> Okay, so lets say that en_10fdx_cap and en_100hdx_cap are set; does >>> this >>> affect negotiation? Is there a heuristic for choosing the correct cap? >>> >> >> It's a strict priority defined by 802.3 section 28.2.3.3 and Annex >> 28B.3. It has to be -- otherwise, there'd be no hope of >> interoperability when a pair of systems have two or more modes in >> common. >> >> For those two, 100Mbps half-duplex has higher priority than 10Mbps >> full-duplex. In general, it's speed first, then duplex. >> >> As for "why," this is much better than bluntly disabling >> autonegotiation. With autonegotiation disabled on just one side of >> the link (the common installation error case), the partner is forced >> to fall back to its lowest setting (10Mbps half-duplex), and nothing >> works. >> >> Better still, of course, is not to touch the fiddlin' bits. ;-} >> > > Right, see > http://gdamore.blogspot.com/2008/08/why-you-dont-want-to-force-link-modes.html > for my most recent rant on this particular topic.
I'm suddenly reminded of hours spent in the lab years ago trying to get a PIX and ProCurve to play nice... It really sounds like this behavior could be abstracted out and placed into a capability. Essentially all you would really need is a couple of utility functions to simplify exposing a set of adv_ props, and to read (in order of 802.3 precedence) a set of config modes. Thoughts? Steve _______________________________________________ networking-discuss mailing list [email protected]
