Source-linked AI summary
Implementing Data Diodes Using Commodity Hardware and Open Source Software
Peter Story, Gert-Jan den Besten
TL;DR
Data diodes provide one-way data exchange, but receivers cannot request retransmission of dropped packets, making reliable transfer software important. The paper measures packet loss, evaluates existing transfer programs, and develops pydiode; its results show data diodes can be assembled with commodity hardware and open-source software for a fraction of commercial cost.
Problem
Data diodes need specialized software to transfer data reliably because receivers cannot request retransmission of dropped packets.
Source: §1 · p. 1Method
The authors measured packet loss, tested netcat, UDPcast, and lidi, and developed pydiode for reliable one-way transfers.
Source: §1 · p. 1Results
Data diodes can be assembled using commodity hardware and open-source software for a fraction of the cost of commercial devices.
Source: §7 · p. 14Takeaways & Limitations
Lower-cost data diodes can let security teams test their suitability with minimal capital investment and serve as an educational tool.
Source: §7 · p. 14Testing covered only configurations requiring no superuser privileges and two platform settings: Ubuntu 24.04 Intel NUCs and M1 Mac minis running macOS Tahoe 26.2 or Sequoia 15.7.4.
Source: §5 · pp. 11–12
Abstract
from arXiv · showhide
One-way network devices, known as data diodes, are used to defend against sophisticated cyberattacks. Partly due to their high cost, data diodes are mostly deployed in nuclear power plants and within the government for handling classified information. Although commercially available data diodes are expensive, a data diode's hardware can assembled from commodity fiber-optic network equipment. However, specialized software is needed to send data through a data diode reliably: the receiving program cannot request retransmission of dropped packets, so packet loss must be minimized and mitigated. First, we developed a minimal program to measure packet loss. We found that most packet loss was caused by the receiving program processing incoming packets too slowly, and that packet loss often occurs in clusters. Also, we discovered ways to minimize packet loss on Linux and macOS without using superuser privileges. Next, we tested three existing open source programs for one-way data transfers: netcat, UDPcast, and lidi. Although these programs were unreliable in their default configurations, we identified reliable configurations for UDPcast and lidi. Finally, we incorporated our findings into pydiode, our cross-platform program for reliable one-way data transfers.
1 Introduction
Data diodes physically enforce one-way transfers, offering a more secure and usable alternative to air gaps that can be impractical. Commodity fiber-optic equipment can provide the hardware, but reliable transfers require specialized software because receivers cannot request retransmission.
1 Introduction
- Zero-day attacks target high-value systems, while software defenses offer limited protection because they can themselves be hacked.The introduction describes physically isolating devices as one approach to defending against such attacks.Source: §1 · p. 1
- Air gaps can be impractical because devices still need to exchange data, making manual USB transfers cumbersome.The passage begins a description of manual transfer across an air gap and characterizes it as cumbersome.Source: §1 · p. 1
- Data diodes are physically limited to one-way transfer and can use commodity fiber-optic hardware, but require specialized software to manage packet loss.Commercially available data diodes can cost more than $100,000; receivers cannot request retransmission of dropped packets.Source: §1 · p. 1
1. What causes packet loss in data diodes?
The section asks what causes packet loss, how existing one-way transfer programs perform, and whether the authors' software can transfer reliably faster. It reports receiver-side processing as the dominant loss source and identifies platform-dependent reliability findings and reliable configurations.
1. What causes packet loss in data diodes?
- 99.99% of packet loss was due to RcvbufErrors caused by the receiving program processing incoming packets too slowly.The study measured packet loss while transferring terabytes through a commodity-hardware data diode.Source: §1 · p. 1
- Larger packets increased reliability on Linux but could decrease reliability on macOS.The authors report this as a counterintuitive platform-dependent finding.Source: §1 · p. 2
- Minimal and pydiode offer faster reliable transfers than UDPcast and are 52% and 46% slower than lidi, respectively.The comparison is reported for reliable transfers.Source: §1 · p. 2
- Netcat transfers succeeded 93.89% of the time, while UDPcast and lidi were unreliable by default but had reliable configurations.The authors incorporated their findings into pydiode, a cross-platform program for reliable one-way transfers.Source: §1 · p. 2
2 Related Work
The related work connects zero-day threats with physical controls on information flow, reviews where data diodes are used, and surveys open-source transfer software. It highlights the need for reliable software because one-way transfers cannot request retransmission of dropped packets.
2 Related Work
- The related-work review covers zero-day attacks, air gaps and data diodes, existing deployments, and open-source transfer software.These topics frame the paper's treatment of data-diode security and software.Source: §2 · p. 2
2.1 Zero-Day Attacks
- Zero-days are valuable unpatched vulnerabilities, often reserved for high-value targets, though AI may accelerate exploit discovery.Software defenses can be evaded or hacked themselves.Source: §2.1 · p. 2
2.2 Air Gaps and Data Diodes
- Air gaps can impede communication, while physically one-way data diodes enforce information-flow direction and support confidentiality or integrity guarantees.The cited models connect confidentiality with preventing information from leaving a protected system and integrity with preventing lower-integrity inputs.Source: §2.2 · p. 2
2.3 Existing Deployments of Data Diodes
- Data diodes serve military, intelligence, and safety-critical public-sector settings, while commodity fiber-optic hardware can cost less than $100.The passage notes that proprietary products can exceed $100,000 and that adoption may be limited by complexity and cost.Source: §2.3 · pp. 2–3
2.4 Open Source Software for Data Diodes
- Open-source UDP software supports data-diode transfers, and the authors selected netcat, UDPcast, and lidi because each accepts flexible stream input.The software survey is not necessarily exhaustive; hairgap was considered but could not be compiled and was not actively maintained.Source: §2.4 · p. 3
3 Method
The method section describes assembling a data diode and connecting workstations, then testing existing transfer software and implementing two programs for measurement and reliable transfers.
3.1 Hardware Configuration
The experiments used a commodity fiber-optic data diode and paired workstations on Linux and macOS. The setup connected the sender and receiver through the diode while supporting direct workstation management.
Data Diode Assembly
- Two media converters and a single-mode fiber splitter formed the diode; the sender’s TX-to-RX loop is required for Ethernet autonegotiation.The receiver’s TX port was covered with electrical tape.Source: Data Diode Assembly · p. 3
Workstation Configuration
- Two Linux PCs connected through the diode were also linked directly for SSH control and to the campus network for remote management.The researchers confirmed transfers used the diode by monitoring the converters’ activity lights.Source: Workstation Configuration · p. 3
- Two M1 Mac minis used the same network arrangement as the Linux PCs.Each had 16 GB of RAM and 512 GB of storage.Source: Workstation Configuration · p. 3
3.2 Software Configuration
The study tested transfer programs on Linux and macOS, emphasizing configurations available without superuser privileges. Repeated 1 Gbit transfers and checksum comparisons were used to identify configurations that minimized duration while succeeding in every trial.
3.2 Software Configuration
- The experiments focused on unprivileged settings to inform Linux and macOS use, with findings also relevant to future testing on Android and iOS.The Linux and macOS network configurations used manual ARP entries; Linux network namespaces isolated diode traffic, while macOS used equivalent interface addressing.Source: §3.2 · pp. 3, 5
- Each trial transferred 1 Gbit of random data, checked sent and received checksums, and recorded network statistics to diagnose packet loss.The goal was the shortest transfer duration for which all transfers succeeded.Source: §3.2 · p. 5
Configuring netcat
- The tested OpenBSD netcat implementation offered no options for increasing transfer reliability.It was the netcat-openbsd package installed by default in Ubuntu.Source: Configuring netcat · p. 5
Configuring UDPcast
- UDPcast tests varied transfer rate and forward error correction settings, including the number of stripes and data and repair packets per stripe.The tested version was the latest available through Ubuntu’s package manager at the time.Source: Configuring UDPcast · pp. 5–6
Configuring lidi
- lidi’s transfer rate was not configurable, so tests varied its repair-data percentage; failed transfers were timed out after 60 seconds and counted as failures.Its default repair data was 2% of the original data, associated with blocks of 734,928 bytes.Source: Configuring lidi · p. 6
3.3 Software Development
The authors built a minimal program to measure packet loss and used those findings to develop pydiode for reliable one-way file transfers. pydiode uses repeated, sequenced chunks and a digest-bearing end marker to mitigate loss and detect transfer errors.
3.3 Software Development
- The minimal program established a performance baseline and recorded dropped packets, while pydiode added loss mitigation and transfer-error detection.Both programs were developed for one-way transfers; pydiode targets Linux and macOS without requiring superuser privileges.Source: §3.3 · p. 6, Developing pydiode · p. 6
Developing a Minimal Program
- The Python minimal program sent UDP packets from standard input and received them until 200 ms without a packet, then wrote payloads to standard output.Packet-detail logging retained packet digests so sender and receiver records could identify dropped packet indices.Source: Developing a Minimal Program · p. 6
Developing pydiode
- pydiode reassembles chunks by packet sequence number, outputs them after all packets arrive, and checks the received data against the final SHA-256 digest.It uses retransmission and padding to maintain the configured bitrate; payload sizes and receive-buffer requests differ by operating system.Source: Developing pydiode · pp. 6–7
- Linux and macOS showed rare, unpredictable packet-loss clusters of up to 80 packets; pydiode’s default 100-packet chunks, sent twice, tolerate up to 100 sequential losses.The diagram shows alternating red and blue chunks and a black end-of-file chunk carrying a SHA-256 digest.Source: Developing pydiode · p. 6, Figure 2 · p. 7
4 Results
The evaluations apply packet-loss findings to existing one-way transfer tools and pydiode. Redundancy enabled failure-free pydiode transfers on Linux, while all tested macOS transfers succeeded.
4.1 Performance Baseline on Linux
- 99.99% of packet loss came from RcvbufErrors; the fastest reliable unprivileged Linux configuration used helper writes, 65,507-byte payloads, and a 500 Mbit/sec limit.Increasing the receive buffer to 8.4 MB left only one failed transfer across four configurations, but required superuser privileges. Unexplained losses clustered, with dropped packets adjacent or close together.Source: §4.1 · pp. 7, 9
4.2 Performance Baseline on macOS
- On macOS, an 8.4 MB receive buffer made every tested 1,472-byte-payload transfer at 1 Gbit/sec succeed, while every 213 kB-buffer transfer failed.Unlike Linux, 65,507-byte payloads could be less reliable on macOS; the three failures with an 8.4 MB buffer all used those payloads at 1 Gbit/sec.Source: §4.2 · pp. 9–10
4.3 Evaluating netcat on Linux
- 93.89% of netcat transfers succeeded; minimal’s single-threaded, unlimited-rate configuration with 65,507-byte payloads succeeded in 99.61% of transfers.Netcat sent 16,384-byte payloads, and the authors suggest processing fewer packets may explain minimal’s better performance.Source: §4.3 · p. 10
4.4 Evaluating UDPcast on Linux
- With UDPcast, 8x32/128 FEC at 500 or 750 Mbit/sec yielded no failed transfers; 8x8/128 and 8x16/128 were unreliable at all tested bitrates.Without FEC, transfers had high failure rates; FEC sometimes failed when RcvbufErrors occurred, particularly with large numbers of dropped packets.Source: §4.4 · p. 10
4.5 Evaluating lidi on Linux
- With lidi, transfers became reliable at FEC levels of at least 50%, compared with the default 2%.Among transfers with nonzero RcvbufErrors, 71 of 79 using 2% FEC failed, while all 93 using 50% FEC succeeded. Lidi sent payloads up to 1,468 bytes; the authors expect larger payloads might reduce RcvbufErrors.Source: §4.5 · p. 11
4.6 Evaluating pydiode on Linux
- On Linux, no pydiode transfers failed when redundant transmissions were enabled.The tested configuration used 65,507-byte payloads sent to a broadcast address without superuser privileges.Source: §4.6 · p. 11
4.7 Evaluating pydiode on macOS
- On macOS, all tested pydiode transfers succeeded, both with and without redundancy.The tested configuration used 1,472-byte payloads sent to a broadcast address without superuser privileges.Source: §4.7 · p. 11
5 Limitations
The evaluation is limited to configurations usable without superuser privileges and to two specific computer and operating-system platforms. The authors also report platform reliability issues, including kernel panics during extended Mac mini tests.
Platform and configuration limits
- The tests covered only Ubuntu 24.04.3 LTS on Intel NUC 12 mini PCs and macOS Sequoia 15.7.4 on M1 Mac minis; mobile devices and Windows were not tested.The authors note that reliability varies by platform, and describe Android and iOS as sharing network stacks with Linux and macOS, respectively.Source: §5 · p. 11
- Testing used only configurations that required no superuser privileges, excluding larger network buffers and changes to process priority.The authors chose this scope to include contexts such as mobile devices, where privileged configurations may be incompatible.Source: §5 · p. 11
Platform reliability issues
- The authors also observed occasional SSH disconnections on a secondary PCI Ethernet port during test automation; switching to USB-C Ethernet stopped them, and the primary built-in ports had no one-way-traffic issues.The issue concerned the testing setup, not the primary ports used for one-way traffic.Source: §5 · p. 11
Evaluation scope
- The pydiode comparison ran 10,000 trials per configuration, transferring 1 Gbit each on Linux and macOS.The fastest reliable configuration identified on each platform and the reliable but slower defaults are distinguished in Table 6.Source: Table 6 · p. 12
Platform reliability issues
- Repeated 1 Tbit pydiode streams on three M1 Mac minis triggered kernel panics after 35, 48, and 71 hours; the authors anticipate an obstacle in industrial contexts, but not for end users.Panics occurred on both sender and receiver machines, using macOS Tahoe 26.2 and Sequoia 15.7.4.Source: §5 · p. 12
6 Discussion
The discussion attributes most observed packet loss to receiver unresponsiveness and describes ways to minimize or mitigate it. It compares reliable configurations of one-way transfer programs and offers implementation advice for developers.
6.1 Packet Loss Is Caused by an Insufficiently Responsive Receiving Program
- 99.99% of packet loss was attributed to an unresponsive receiver; UDP-buffer overflow caused clusters, so redundant information should not occupy adjacent packets.Rare losses lower in the network stack also occurred in clusters.Source: §6.1 · p. 12
- Packet-loss controls include a helper thread for writing received data, larger payloads on Linux, and larger receive buffers on macOS; slower transfers sometimes reduced reliability, and larger packets could reduce it on macOS.The authors suggest retransmission and padding to maintain consistent output bandwidth when a sender reads a variable-bandwidth stream; optimal payload size depends on platform.Source: §6.1 · p. 12
6.2 When Properly Configured, Multiple Programs Offer Reliable Transfers
- Only 93.89% of netcat transfers succeeded, and UDPcast and lidi were unreliable by default, but configured versions of both completed all transfers successfully.The evaluated programs were netcat, UDPcast, and lidi on Linux.Source: §6.2 · p. 13
- The fastest reliable configurations showed that minimal and pydiode transferred data faster than UDPcast, while they were 52% and 46% slower than lidi, respectively.The comparison concerns each program's fastest configuration for which all transfers succeeded; netcat was omitted because only 93.89% of its trials completed successfully.Source: §6.2 · p. 13, Table 7 · p. 13
- FEC can improve reliability but is neither necessary nor sufficient: a receiver that reads its UDP buffer too slowly can drop more packets than FEC can correct.Neither minimal nor pydiode uses FEC.Source: §6.2 · p. 13
- Program choice also depends on platform availability, broadcast support, codebase size, dependencies, and patent considerations, not only transfer speed.Only pydiode supports macOS and broadcast addresses among the compared programs; UDPcast alone supports Windows at the time described.Source: §6.2 · p. 13
6.3 Advice For Software Developers
- Developers should establish a simple-program performance baseline, minimize packet loss before adding mitigation, and use modular, stream-based input for file, directory, or proxy transfers.The authors caution that FEC can increase packet loss if it makes a receiver less responsive; pydiode's stream interface supports tar pipelines and protocol proxies.Source: §6.3 · p. 13
7 Conclusions and Future Work
The authors conclude that reliable one-way transfers can be implemented with commodity hardware and open source software, and identify more efficient packet-loss handling, commercial comparisons, and alternative hardware as future work.
Conclusions
- Commodity hardware and open source software can implement reliable one-way transfers, offering a lower-cost alternative to expensive commercial data diodes.The authors identify greater access, supply-chain diversification, and avoiding vendor lock-in as potential benefits.Source: §7 · p. 14
Future Work
- Future work includes improving packet-loss minimization and mitigation, comparing open source solutions with commercial products, and developing and evaluating alternative diode hardware.The relative reliability of commercial products is unclear because vendors do not publish reliability data.Source: §7 · p. 14
A Supplementary Figures
The supplementary figures show experimental configurations, command examples, and code for the evaluated data-transfer programs, along with an MQTT proxy example.
Figure 3
- The Figure 3 tests ran each configurable-option combination 10,000 times with randomly generated data.The figure concerns transferring data through the data diode.Source: Figure 3 · p. 17
Figure 4
- Figure 4 shows netcat send and receive commands; -u selects UDP, -s sets the source address, and -w 1 makes netcat exit one second after reception stops.Even small transfers take at least one second with the shown timeout option.Source: Figure 4 · p. 17
Figure 5
- Figure 5 shows UDPcast commands: --max-bitrate sets raw bitrate, --fec sets the stripe and FEC parameters, and three arguments enable asynchronous mode.Actual payload bitrate is lower than the raw bitrate because of packet headers, FEC, retransmissions, and other overhead.Source: Figure 5 · p. 17
Figure 6
- Figure 6 shows lidi commands, with --repair setting repair data as a percentage of the original data..Source: Figure 6 · p. 18
Figure 7
- Figure 7 presents minimal-program code with argument parsing and packet-loss logging omitted; it shows the helper-thread output method because it performed best.Code for other write methods is omitted.Source: Figure 7 · p. 18
Figure 8
- Figure 8 depicts an MQTT proxy that sends broker data from a high-integrity industrial network through a diode to a low-integrity business network.The example is presented as a way to access that data without exposing the high-integrity network to cyberattacks.Source: Figure 8 · p. 19