Simulate/Deactivate link status recognition for 100BASE-TX [closed]

Question

My question is related to creating an unidirectional network cable.

I used these tutorials:

• Receive-only UTP cables and Network Taps
• ONE-WAY CABLE FOR IDS DEPLOYMENT

In principle it works by cutting a Category-5 cable in half, connecting the transmit pair (pins 1 and 2) of the sending side to the receive pair of the receiver side (pins 3 and 6), but you also have to connect pins 3 and 6 of the sending side to your bundle, creating some kind of loopback on the sender side. So in the end you have a point where three cables are connected and the link is working fine (you can send data in one direction etc.). If you do not create this loopback it does not work and the link does not come up on the sender side (on the receiver side it does!).

My question is: Why is that the case? Why can't I just connect the TX and RX wires of sender and receiver?

My guess is that it is related to the link pulses used for autonegotiation. My hope was that these are not present if I disable autonegotiation, which I did successfully with ethtool. (I also set the speed to 100 mbps and duplex to full.)

Yet the link still does not come up. So there must be more to that. Maybe there is also some way to tell the sender side that the link it is up. But I don't know if the link status is handled by the driver or directly by the chip (AX88772B).

Answer 1

I've used read-only cables for similar purposes: invisible syslog sinks.

My understanding is that in 100baseT only autonegotiation is done with the "fast link pulse" FLP, while link-connectivity is still done with the "normal link pulse" NLP.

The suggestion of using a third interface, to prop up the link, should work. I'd love to try this:

• sniffer sees link of sniffee, own link pulses get lost, sending will go nowhere as it's not connected
• prop sends link pulses but sees no link pulses, hence will send nothing

• sniffee sees link pulses so brings line up, and will send

  sniffee                       sniffer
     1 >--------------------+      1
     2 >------------------+ |      2
     3 <------------+     | +----> 3
     6 <----------+ |     +------> 6
                  | |            prop  
                  | +------------< 1
                  +--------------< 2
                                   3
                                   6
  

For the prop, I'd think of something like a computer with no disk, trying to PXE boot.

Answer 2

You are forgetting how ethernet works. An interface needs to know the line protocol is up. Ethernet (CSMA/CD, where the CS stands for Carrier Sense) listens that the line is clear before sending. When the receive pins hear a connection, the interface will work, otherwise the interface doesn't think it is connected to anything, and it will not work.

For example, on a Cisco device without the receive pins active, you can do show interfaces FastEthernet0/0, and the first line of the response will be:

FastEthernet0/0 is up, line protocol is down

What you need is that the receive pins be active so that you get:

FastEthernet0/0 is up, line protocol is up

The same thing happens with a fiber pair when the receive fiber strand is disconnected.

Doing what you want to do will also cause problems for the upper-layer protocols. For example, when IP wants to send to another host on ethernet, it will ARP for the MAC address, and it will need to get a reply before it can send. You will need to create static ARP table entries in your hosts for the receiving hosts. TCP requires a bidirectional connection in order to function. There are many protocols in networking which are dependent on the request/response behavior.

Answer 3

AIUI 100BASE-TX without autonegotiation relies on carrier detection to determine if the link is up.

I wonder if a possible soloution would be to get a third network card and hook it's transmit lines up to the receive lines on the card used to send data.