# Does disconnecting the Tx+ and Tx- wires in the ethernet cable make it Unidirectional for Packet (TCP) sniffing

The DCSW-1005(10/100Base-T) Ethernet switch/TAP can be used as a network TAP (as well as Ethernet switch), in which a copy of outgoing and incoming packets associated with Port 1 (Target port) are forwarded to Port 5 (Monitor port).

The Packet_analyser sniffs the packets between the TCP_server and the TCP_client using port_mirroring enabled DCSW-1005(10/100Base-T) Ethernet switch/TAP as shown in the figure.

That means the Packet_analyser doesn't have to send any TCP hand-shake siglals (which will be taken care by actual TCP_client) but still receiving all TCP packets involved between the TCP_server and the TCP_client, hence I cut the TX+ and TX- wires of the cable C3 (cat-6 Ethernet cable, which will carry data from Packet_analyser towards Port 5 of the switch) thinking it will make the cable unidirectional, but it is not working.

So how can I receive the packets with TX+ and TX- wires from Packet_analyser are open (cut).

• It's possible that with the wires cut, the other end (the switch port) thinks that there is no cable connected and therefore doesn't send anything. – alex.forencich Jan 8 at 9:52
• Why do you think you need to cut these wires exactly? – Finbarr Jan 8 at 10:02
• @ Finbarr, My application needs to be tested in the actual network (SCADA network where TCP_server is RTU and TCP_client is Control station in the Power-grid), so this is the way they allow me to connect my Alalysis_machine to their network (to protect their critical network from unknown vulnerabilities). – reddi hari Jan 8 at 10:17
• If I connect my Packet_analyser to the Switch with TX+ and TX- wires cut, then there will be no Ethernet connection. – reddi hari Jan 8 at 10:20
• But If I connect first (connection established and able to capture the packets, checked with wireshark) and then cut the TX+ and TX- connection still there but unable to capture packets. – reddi hari Jan 8 at 10:36

Three things.

Firstly, what layer are you doing the forwarding on? Without the ability to respond to ARP requests you will really need the switch to be doing dumb forwarding to a specified port at the ethernet level, I keep an old 10base-T switch around for this sort of thing. In particular the switch will not be able to discover your mac address and thus will not be able to figure out which port to forward to without help, most switches will also power down a port that does not have carrier present, so you will need to work around that.

Secondly, you probably need to hack the PHY (and maybe also the MAC) configuration registers to avoid the thing going to low power/port disconnected mode. A 100R resistor across the TX pair MAY help here, but it is going to depend a lot on the specific chip in play, download the chips datasheet and have plenty of coffee ready.

Thirdly, without ARP, the TCP stack will likely not do anything reasonable so you really want to be doing the interception at the ethernet frame level, not the higher levels of the stack.

In general this kind of 'data diode' is more trouble then it is worth, it can be done, but the easy way usually involves either custom network drivers or some very funky switch configuration, usually a small computer with three network interfaces (or two interfaces plus a high speed unidirectional port) is the easy way (And besides this way you find out which way a given frame is travelling), MITM has much to recommend it.

• I tried these answers. but they are not working, maybe because of Auto MDI-X or Autonegotiation. is there any way I can do it by disabling them (for example: ethtool --change eth0 speed 100 duplex half autoneg off or ethtool -k --off load eth0 tx off rx on) – reddi hari Jan 11 at 6:30