I've tried building a network tap with only three ports: the two communicating parties and a tap side. I knew this would force the communicating sides to use at most half-duplex 100mbps, but detection is not an issue (I'm tapping my own hardware to better learn how it works under the hood). I've made 4-port taps before, but was still only able to tap one side at a time because my laptop has only one network port and I don't have a USB NIC.
The problem is that my attempt at the 3-port tap doesn't work.
I used one normal cat5e cable connecting the two communicating parties and half a cable (with only one RJ45 connector) as tap. I connected TX+ and TX- (pins 3 and 6) from the main cable to RX+ and RX- (pins 1 and 2) on the tap cable like with a normal 4-port tap. This worked. (Except I never knew which side's traffic I was tapping because auto-MDIX automatically selects which side uses pins 1 and 2 to transmit and which uses 3 and 6 (unless connected to a switch), but that was expected.)
Then I connected pins 1 and 2 of the main cable to pins 1 and 2 on the tap cable as well. This causes pins 1 & 3 and 2 & 6 to suddenly be in the same collision domain, so when one starts sending the other side will receive it on both the receive and transmit pins, and will not be able to transmit during that time (or if it accidentally does, CSMA/CD kicks in).
At least that was the theory. Autonegotiation should detect the shared collision domain and switch the sides to 100mbps half-duplex ethernet. Except this never worked… both parties just became to be unable to transmit any data.
Why is this? My logic of building a network tap like this is probably faulty somewhere, but I can't really figure out why. If this doesn't work, why does the term "half-duplex ethernet" exist at all? What other situation can you have where you have a half-duplex ethernet connection?
Alternatively, is there any way I can tell my NIC that it should treat both pins 1&2 and 3&6 as receiving? I'm using Linux, but I'm afraid I'll have to go beyond tooling and modify the driver, right?
I'm sorry if I'm making some stupid and obvious mistake in my build, but I can't really figure out a way to make this work. I've also looked at a similar question about why network taps have 4 ports, but the answer there is that the tap side would need 200mbps to receive both ends at the same time (which is not a standard, thus needing 1gbps, thus needing more than two receiving pins). With half-duplex though, only one side can be sending at the same time, so the bit rate is still 100mbps and the speed can't be the issue.
Best Answer
Your thought process is based on faulty assumptions. By splicing 1 to 3 and 2 to 6 (which is what you have done), this does not put them in the same collision domain. Nor does this cause the devices to autonegotiate into half-duplex mode. Connect only one side of your main cable to one device and what you have now created is basically a "loopback."
Look at a hubbed 10BaseT or 100BaseTX environment. While they are in the same collision domain, they still have separate TX and RX pairs, they don't transmit in both directions on the same pair.
The reason for the collision domain is that a hub is ultimately a repeating device, which takes a signal in one port and repeats it out all other ports. If it receives traffic on two ports and repeats it out the other ports, the signal that is repeated will be a "collision" of the two signals creating an unusable signal. Thus the need for CSMA/CD and half-duplex operation.
By having three devices all spliced together in this fashion, you have merely created an environment that won't work. If you want to do this, simply put a hub between your two devices and connect a "listening" device to it. No need for a tap.