I want to build a unidirectional comminucation. In transportation layer of this device, it needs a one-way media to send data from side A to side B.
All commercial products use SFP. I tested some SFP devices but they have negotiation between the two sides and cutting RX fiber is not possible.
Is it possible to implement One-way connection with CAT5 cable?
SideA { tx --> rx } SideB
One-way Ethernet cables won't work with Gigabit network equipment and later, because without a return path the autonegotiation sequence will never complete. You'll see a "Network cable unplugged" or an equivalent message on both devices if you try to use such a cable.
Older Ethernet devices won't work with simple one-way cables either, but can be fooled to do so. This website has practical instructions for building suitable cables. In the essence, you'll have to do something like this:
SideA SideA HUB PORT
------- ------- -------
x x r r x x r r r r x x
6 3 1 2 6 3 2 1 1 2 3 6
| | | | | | | | | |
| +-/ | | | | \-------------/ |
| | | OR | | \-----------------/
+-|---/ | |
| | | |
| | | |
| | | |
6 3 2 1 6 3 2 1
r r x x r r x x
------- -------
SideB SideB
The extra Hub port is needed to provide voltage over the RX pair of SideA, to fool it into believing there's a transmitter on the other end.
If none of the above works, or you cannot disable auto-negotiation, the next best thing is to implement two Ethernet-enabled devices with a one-way data path between them. For example, a couple of Ethernet PICs with a unidirectional UART in between should be able to do the trick.
One thing you should ask yourself before you proceed is whether you really need a data diode. Here's what the experts say:
Most organizations don’t need a new protection technology like data diodes. [...] Assuming the [firewall] rules only allow inside-out, UDP-based communication, and there is no misconfiguration in the firewall, I can’t recall a firewall exploit that would allow an external attacker to gain access into the CCA perimeter.
If you want "one way data direction", you have to do it at a higher level. Various things assume bi-directional communication at the low levels, even if app-level data is only flowing one way.
For example, even if you send data in only one direction over a TCP connection, there will still be packets going back and forth in both directions. You can get away with one-way packets for data by using UDP, but depending on what you're doing it may take bi-directional communication to set up a connection.
You may think you'll just stick to UDP, but many protocols are layered on TCP, which absolutely requires sending packets both directions. Examples include HTTP (web browsing) and SMTP (email).
Ethernet also assumes some bi-directional communication between the two endpoints, even if higher level data is only carried one way. There a link pulses, and possibly some auto-negotiation of low level communication parameters.
To get what you want, you basically have to make your own router (although it can much more stripped down than a arbitrary "router"). Your device still needs to send and receive packets to/from the network. It interprets some of these packets and passes data in only one direction over the other port. Note that this most likely requires bi-directional communication at the low levels again at the other side of the router, even with application-level data flowing only one way.
It is possible on 10BASE-T and 100BASE-TX, but not on 1000BASE-T because the latter uses bidirectional transmission on each pair.
To enable such a mode, you need an MDIO/MDC (management) access to the PHY at least at the TX side of the one-way link, to configure it like the following:
Configuring the RX PHY is optional but may help depending on the hardware specifics. If used, the RX PHY configuration is the same as the TX PHY.
It is equipment specific, but many managed switches (with SFPs or not) provide the user with an ability to manually configure the Ethernet ports via Web interface and/or console. You need to examine the datasheets on your equipment first and then trial on it.
What about other answers, @Dmitry's left scheme may fail because neither 100BASE-TX nor 10BASE-T is intended to be used on single pair from the box, while his right scheme is closer to what you need but where we could get a true hub (not switch) today? and also, a hub works only with 10BASE-T.
Meanwhile @Olin speaks about something (higher level) else but not about the (physical, medium-restricted) data diode you ask on.
Works only at 10/100mbps . If you fix port speed at 100mbps. Loop back Tx+ to Rx+ (and optionally Tx- to Rx-) on the sender and parallelly connect Tx+ and Tx- of transmitter to Rx + and Rx- of reciever. I have observed that Rx should recieve a voltage for the port to be considered enabled. While this is not a problem with the reciever as receiver s rx is connected to sender's TX. The transmitter on other hand has his receive legs free. You can possiblly connect a battery here??!. But simpler solution is to loopback from its own tx.
UDP broadcast is a good option..assuming you are transmitting blindly..and obviously cannot see anything at the other end of the wire responding due to one way setup.multiple transmission of same packets can help in case of packet loss??? Thats for you to figure
There is a solution and it was designed for data diode applications. It is the unmanaged media converter, modified to use in pairs and support one way traffic from B+B SmartWorx. 856-10730-RX and 856-10730-TX
First, for those that don't know what a data diode is or what its uses are, you should start here. There are many VERY good reasons for implementing this type of solution.
https://en.wikipedia.org/wiki/Unidirectional_network
As for how to handle this, you have a number of options. You could purchase an off-the-shelf solution. Some of these solutions are very expensive and come with NSA certification. Other, simpler solutions cost less and will meet your needs, but you'd have to search around. Here is an example of a cheaper solution.
https://www.canarycom.com/index5.html
If you're a bit savvy with copper network cabling, you could try the trick Dimitry points to. Or, if you want to try and use fiber, you could try a similar trick by connecting two "low-side" devices together (Tx to Rx) to keep the Tx of the second device active. I've seen this done with two CAT-to-FO converters and it worked perfectly. I've not tried it on a computer NIC.
Also, for those who are speculating about the transmission protocols, that's what UDP is for. Works wonders when you don't need or expect a response.
