Watch. Catch. Patch

A previous article covered the challenges that can be faced when debugging network protocol problems.
In this article we reveal some of the solutions that we are developing to minimize most of the work that is currently required before getting to the most interesting part, the investigation and correction of the problem.


One frequently overlooked issue in network protocol debugging is the quality of the data. It is not rare to discover after a few hours of work that the data provided or captured are in fact irrelevant to the problem at hand. That can be because the person or mechanism that captured them has its own assumptions about the problem, or made a mistake during the capture, or misunderstood the problem. All these issues can be reduced if the person doing the analysis could capture the data with as few interposing layers as possible by eliminating unnecessary human, software or hardware intermediaries.

To achieve this goal, we recommend our own device, called an E-mim (patent pending). This is an enhanced network tap that is light enough to be installed hanging between two Ethernet cables. It is powered by the USB 3.0 cable connecting it to the computer that manages the data, but it still acts as if the two Ethernet cables are directly connected when not powered. This allows it to be left in place between debugging sessions, even with devices requiring Power over Ethernet.

This device already exists as an alpha release prototype, and we plan to have at least one more alpha prototype and one beta prototype before starting a Kickstarter campaign for the final product, sometime in the last quarter of 2015.


A normal network protocol debugging cycle consists of capturing and looking at a set of packets that contains clues to the problem to diagnose. This is an iterative process, which starts by looking at an overview of all the packets exchanged and then, by filtering out the packets that are not relevant and looking at the details of the packets that are, ends by pinpointing the solution to the problem.

The E-mim device is connected through its USB port to a computer running Windows, Mac OS or Linux. The person investigating the problem use the Nephelion software installed on this computer to interact with the E-mim device. Although the most common tasks can be executed with simple commands, Nephelion is, at its core, a powerful developer tool, which can be used with any language that runs on a Java Virtual Machine.

With the increasing adoption of encryption in protocol networks, traditional tools will slowly lose their usefulness as they won’t be able to look at the packets flowing through the network. In contrast, Nephelion is capable of receiving encryption keys from devices that are under the control of its user, so problems can be debugged without weakening the security of the whole network.


The previous step provides at best a sense of what went wrong, but it can never result in an absolute certainty. The problem can be marked as resolved only after the software that created the issue is fixed and tested. But software takes time to be fixed, which may mean months or even years if the source code is not directly available, as is the case for most network devices.

The E-mim device is, in fact, more than a simple network tap in that it can also modify network packets on the fly. This is how the diagnosis of a network problem can be immediately put to the test by patching the faulty packets directly as they travel through the network.

By providing a simple way to watch, catch and patch protocol network problems directly where and when they happen, Nephelion and the E-mim device provide a unique solution to the increasing complexity of network protocols.