kstratton@fastmail.us wrote:
I just went through some painful debug session(s) with my ISP. For some reason, after forcing 10 base T half duplex through my windows box directly to my modem (I do not expect ISPs to support linux),everything suddenly worked (after reconnection and re-enabling of course).
How often does this kind of thing happen? I have seen this kind of thing before only once before, and I was using an old hub that only supported 10 base T, not a home router that is supposed to autodetect the port type. I remember that the modem only supports 10 base T, but I am not 100% certain.
Does anybody have an explanation of what most likely happened? Do not hesitate to skimp on technical details or references if is convenient. I desperately want to understand what happened.
Actually, that sounds like it's a problem on the PC end. Here's why. Back when there was only 10 half, it was easy to figure out what speed and duplex the other end was running at - 10 half! With 100M ethernet appearing, though, you soon had dual speed cards on the market. Rather than having to configure each and every port explicitly, users wanted to be able to plug in and have the card just do the right thing. Luckily, the signaling was different enough between 10 and 100 that it was relatively straightforward for a 100M card to detect whether the other end was speaking in 10M or 100M, and shift speeds appropriately. This is called, simply enough, autosense. However, speed is only half the equation. Along with 100M ethernet came switches. Switches, by allowing for a pseudo-dedicated link per machine (as opposed to hubs, in which the bandwidth of all links was shared by all stations), introduced and entirely new operating mode - full duplex. Unlike speed, there is no reliable way to passively detect what duplex the other end is configured for. So, to solve this, and also to lay down a foundation for interoperability as future network speeds appeared, the autonegotiation protocol was developed. Essentially, as soon as a link is established, both ends send a few magic packets at each other advertising what speed and duplex combinations it supports. The two ends pick the highest performance option supported by both, switch to that operational mode, and go on their merry way. Even after all this, you'll still see devices appearing which only support 10 half, and don't bother to do autonegotiation. When a newer device that does support autonegotiation is plugged into such an older device, autonegotiation will (obviously) fail. The new end will then default to autodetection for the speed, and will always use half duplex. This is why forcing on end of a link to full duplex, and leaving the other end on auto, will virtually always result in a duplex mismatch, and a link that works, just with really, really crappy performance. Donald Becker used to have a paper floating around describing this in a little more detail. I can't find the original anymore, but this looks like a copy of the same info: http://www.negotiateddata.com/files/Bunch_Article_020095.pdf So in the scenario you described, where the other end is sitting fixed at 10 half, it would have been up to your computer to gracefully fail autonegotiation, and use autosense to configure the link at 10 half. Sadly, such bugs, where chipset manufacturers assume that everyone else out there will always support autonegotiation, are not unheard of these days. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC