Priscilla Oppenheimer wrote: > > Back to the Ethernet question. Does the splitter simply take > the four wires that 10BaseT uses and make 2 wires out of each, > sending one of each to each port? What an awful thing to do to > an Ethernet! You bad boys. ;-)
Quite devious indeed! And yes, the splitter has one male RJ-45 and a modular body that has two female RJ-45s pointing in the opposite direction. Pin 1 from the male goes to pin 1 of both females, etc. > > As Scott mentioned, some books make it sound like the sender > loops back what it sends so that it can compare that with what > it receives back from the hub, sort of implying that the hub > sends back the transmitter's bits to the transmitter. A hub > doesn't do that. And the loopback isn't used to do a bit-wise > comparison with what the hub is sending, like some books imply. > That would be computationally expensive and also isn't > necessary. Simply receiving while you are sending means a > collision occurred. I gave this some thought on my drive home. I've read that NICs internally bridge tx to rx. According to this theory, a comparator circuit outputs zero as long as what is on tx is also on rx. If someone else collides, the comparator outputs something other than zero, because what is on rx is now a combination of the colliding signal and what tx was outputting. Does that make sense? I realize this may be urban myth (especially since, as you pointed out, this is a lot more expensive than just declaring a collision if you rx while tx'ing), but it would be interesting if some or all NICs actually did this. Because then, although CSMA/CD still wouldn't work for the reasons already mentioned, the collision between the two stations would be detected and backoff would take place. Otherwise, it would be up to upper layer protocols to retrans. > > What this means is that in this RJ45 splitter situation, the > two senders don't know when the other one is sending. The hub > isn't putting it back onto their receive wires. They can still > do ordinary collision detection if some other station in the > collision domain sends while they are sending, but they can't > hear each other. > > The result must be severly errored frames that the hub merrily > propagates to all ports! That's very bad. I think the only > reason it works is because the recipient NICs drop the garbage > and upper layers at the sender retransmit. Also, it works > because the stations aren't actually sending at the same time a > lot of the time. > > Now I wonder why the splitter didn't work on the switch? Did > the switch diable the port due to the high number of > CRC-errored frames or did it recognize some other problem?? Was > there a link light? Just for old times sake, I plugged that splitter back into a wall jack and tried it with our switch (unfortunately, that sits where I couldn't easily get to it, so I can't answer the link light question at the moment). Sure enough, I got that "cable unplugged" popup on both machines. I'm guessing that your'e right about the switch locking out the port. Our IS folks were gone for the evening, so I couldn't ask them if they have the ports locked down to a single MAC, or anything along those lines. It might simply be that having two NICs on a switch port causes impedence issues that didn't affect a hub in quite the same way? Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55768&t=55667 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
