This page has a very simple purpose: to hold links to a couple videos.
Videos of oscilloscope action, looking at an unconnected Ethernet port,
trying some initial chirping to negotiate a link.
In other words: the videos do not show the full clause 28 handshake,
just the initial "challenge".
These recordings were taken while trying to debug a mysterious "flakey NIC" problem. Turned out that the culprit port probably was merely configured for 100/full, which made it "behave differently" and have difficulty establishing link in a particular scenario: a particular switch model and configuration, and specifically, the opposite port was configured to use autonegotiation. In fact, failure was the likely outcome all along :-) due to the mutual misconfiguration. The Ethernet hardware involved was otherwise perfectly healthy and adhering to applicable standards.
The pulses displayed with "auto-negotiation enabled" are likely the Link Integrity Test pulses, probably of the FLP subtype (rather than NLP) considering that the ports are 10/100 Mb or 10/100/1000 MB. The oscilloscope used has too little memory to capture a whole FLP burst at its highest resolution, and I decided to zoom in on a single LIT pulse.
The purpose actually is to show the difference on the oscilloscope, of standard auto-negotiation, vs "100Mb full duplex and auto-negotiation off" - and, to point out what auto-mdi-mdix looks like (automatic accomodation of straight vs. crossover cable).
The following two static pictures are meant as clickbait. In order to show activity at both traces, they contain a bit of digital decay. If you take a snapshot without decay, you will always see only one direction active, unless you're eavesdropping on an established duplex link.
The standard 10Mb LIT pulse (autoneg on), NLP or FLP
100Mb / full duplex forced, autoneg off, auto MDI/MDI-X on
Again this is a single port, not connected to a peer Ethernet port. The green and orange pair are terminated by 100 Ohms, and sensed by high-impedance oscilloscope probes at those terminators. The DUT provides output at both pairs, in turns.
To see the promised videos, click the links in the text below.
The first video shows a DM9102, which is a 10/100 Mbps NIC chip on the PCI bus, proposing to initiate a standard auto-negotiation handshake, as per IEEE 802.3 clause 28. Things to note:
1) there's a pulse that's approx. 100 ns long, i.e. 1 bit at 10 Mbps. This is the mandatory initial rate for the clause 28 handshake. Even multirate 10/100/1000 Mbps ports start the handshake this way (theoretically 100/1G/10G ports as well, despite not having support for 10Mb payload transfers).
2) note how fast the NIC takes turns in sending the pulse out the orange or green pair. It tries to "throw this and that and see what sticks". If an opposite port appears on the line, it will respond accordingly. Note how quick the "direction turning" happens - about once a second, with just a bit of random fluctuation.
The second video shows the same DM9102, configured for 100Base-TX full duplex and no auto-negotiation. What you see is the 100 Mbps bitstream, but still the port tries "this and that direction" in turns. I.e. the MDI/MDI-X still gets established automatically. Note how fast the "turning" is, and it seems to go on like this forever (or nearly).
The silent pair is in reception mode = lurks around, waiting for an incoming bitstream at the same bitrate. If two such ports turn out to face each other, the physical link gets quickly established, based on the incoming signal edges detected at both ends. No auto-negotiation communication about parameters takes place though. Just the link comes up, and the parties can start forwarding data.
The third video shows the 10Mb auto-negotiation LIT pulses produced by a D-Link switch (probably some Marvell or Realtek on the inside). The port is capable of Gigabit operation (multirate 10/100/1000). Compare the shape and timing of the pulses to the first video above. Note that the sequencing (timing) is much more random compared to the venerable DM9102. The randomness is deliberate, its purpose is to avoid "clashing in incompatible opposing roles" while trying to achieve the initial handshake.
This twiddling goes on forever.
The fourth video shows the 10Mb auto-negotiation LIT pulses produced by an Intel i210 NIC. This hardware is capable of 10/100/1000 Mbps. Looks similar to the previous D-Link. Possibly the random behavior is mandated by the more modern revisions of the 802.3.
Curiously, here this twiddling only keeps going on for about 10 seconds after plugging the cable in, then the LIT's become much more scarce. The LIT's also seem to occur on the blue and brown pair - which correlates with the transmission scheme of 1000Base-T. Overall it seems as if the i210 can detect a cable being plugged even in a passive way, possibly by sensing load impedance / reflections / crosstalk, and responds to any such change by intensifying the auto-negotiation efforts for a few moments. If there's no handshake, it backs off again.
Videos #5 and #6 show the i210 configured for "100 Mbps, full duplex, no auto-negotiation". In that case, similarly to the DM9102, the i210 produces a bitstream at 100 Mbps right away. But, curiously, the switching of directions for auto-MDI/MDI-X takes much longer, maybe several minutes. That's why there are two of them, one video for each direction: yellow and green. Actually, I have once spotted an intermediate stage inbetween, lasting just a couple seconds, where the NIC would switch directions faster (like once per second). This moment is difficult to catch.
The outcome of the troubleshooting session was, something we'd known for quite some time superficially: if you decide to suppress auto-negotiation and force a particular speed+duplex, then you have to force the speed+duplex at both ends, because if you leave auto-nego on at one end, it won't work against the port that is forced (and auto-nego turned off). Regardless of what your switch GUI or your server's config software may want you to believe, there is a difference between just forcing the port into a fixed baud+duplex (and turning auto-negotiation off), vs. leaving auto-nego on and merely constraining the set of bitrates advertised.
By: Frank Rysanek [ rysanek AT fccps DOT cz ]