3

My question is related to creating an unidirectional network cable.

I used these tutorials:

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).

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it. – Ron Maupin Aug 7 '17 at 12:41
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.

| improve this answer | |
0

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.

| improve this answer | |
  • Thanks for the clarification. Do you know any way to make the receive pins on the sender side think that the link is active? Or can this mechanism somehow be disabled? I know that disabling CSMA is possible with some wireless devices by hacking the driver. But I don't know how this is handled by an ethernet device. I'am also aware of the issues caused by this unidirectional approach. However, the receiving PC is sort of a dead end. TCP does not work but I can send files to it without problems via udpcast. – cubla Jan 14 '16 at 16:20
  • To what sort of device is the sender side connected? – Ron Maupin Jan 14 '16 at 16:27
  • Both devices are normal notebooks running debian. Both of them have an usb-ethernet adapter with an AX88772B chipset. The adapters are connected with the unidirectional cable. – cubla Jan 14 '16 at 17:16
  • Your problem is that you don't have a normal connection which you are trying to tap. If you have two devices carrying on a conversation through a hub, you can make a cable to tap into the hub and see the conversation. This isn't made to be between only two devices the way you are attempting. It also won't work using a switch, but a lot of switches can do SPAN to accomplish the same thing. – Ron Maupin Jan 14 '16 at 17:38
  • The purpose is not to create a network tap but to have a cheap and still rather secure data diode (en.wikipedia.org/wiki/Unidirectional_network). Ideally no traffic should ever leave the receiver side e.g. in case it is hacked. – cubla Jan 14 '16 at 18:30
0

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.