Stop guessing.
Start verifying.

NOTBOX is a hardware network impairment device that sits inline on a live Ethernet link, between the device under test and the upstream network. The device under test runs no extra software.

Latency spans 0 to 10,000 ms and jitter 0 to 1,000 ms. Packet loss covers the full range to 100%, bandwidth 1 Kbps to 1 Gbps. Upload and download take independent settings, which reproduces an asymmetric link instead of approximating one.

NOTBOX does the impairing. No agent runs on the endpoint, so the same test reaches hardware that cannot run test software at all: IoT devices, phones and tablets, printers, PLCs. Anything with an Ethernet port, or able to join a Wi-Fi network, qualifies.

Simulate packet loss on the download path alone. Simulate latency in a single direction. Simulate network delay on an otherwise clean link, and watch which timeout fires first. Teams use it as a WAN emulator before deployment, and as a packet loss simulator during QA.

The HTTP API exposes every parameter, so a set of conditions scripts into CI once and replays exactly. A fix then proves out against the same conditions that exposed the fault.

The same box works as an inline packet capture device. It already sits in the traffic path, so capture works without a span port or a managed switch, and without touching the surrounding network.

The summary builds while the capture runs: DNS lookups and the addresses they returned, top talkers and conversations, protocol distribution, TCP health, and a session timeline. Nothing waits for a file to finish. For deeper inspection, the pcap exports straight to Wireshark.

That summary matters more than it first appears. A capture that exists only as a 200 MB pcap goes unread. A capture that opens as “this host requested that name, received no answer, and retried nine times” becomes actionable in a minute.

As packet capture hardware rather than software, the machine under test stays untouched. The unit travels to the site where the fault occurs, which makes portable packet capture practical on a bench that moves.

Port Mirror Mode covers the network tap use case. A host running Wireshark connects to the mirror port and sees traffic crossing the link in real time, with no span port and no managed switch involved.

Capture and impairment share one bridge. A single pass degrades the link and records the response, putting fault and evidence in one file. The HTTP API drives the whole workflow, so the unit can run unattended through a soak test.

Impairment and capture answer questions about a link under test. Monitoring answers a different one: whether a link stays healthy over time, and whether yesterday’s reported fault is still there today.

NOTBOX watches up to four destinations at once and samples every 5 to 300 seconds, charting latency and packet loss for each. It keeps thirty days of history. That span separates real degradation from ordinary variance, and shows whether an intermittent fault tracks with time of day.

Bandwidth monitoring runs alongside it, reporting live upload and download utilization per interface plus session totals, across the wired ports and the Wi-Fi test radio. That measures what an application or device consumes rather than what its datasheet claims, which is the number needed when specifying a circuit or setting network requirements before deployment.

A bandwidth utilization monitor is only as good as where it reads. The unit reads inline on the link itself, and nothing self-reports from the endpoint, so a device that under-reports its own usage cannot skew the measurement.

NOTBOX carries its own Wi-Fi 6 test radio. It broadcasts an access point, and the device under test joins it exactly as it would join any other network. No client software, no proxy configuration, no certificate to trust.

Once joined, that device shares a bridge with the wired ports, so capture and impairment both reach it. Adding 400 ms of latency and 5% loss to a phone or tablet, then recording how the app responds, changes nothing on the device itself. That covers Wi-Fi packet capture and Wi-Fi impairment in the same pass.

This makes wireless packet capture practical on devices outside administrative control. Capturing Wi-Fi traffic conventionally means monitor mode, a compatible adapter, and frames that then need decrypting. Here the device joins the network under test, so its traffic becomes ordinary bridged traffic, captured in the clear alongside everything else.

Both 2.4 GHz and 5 GHz are available. Impairment already in effect carries to the radio automatically, so changing band mid-test will not silently leave a device unimpaired.