I’m thinking of starting a new personal project that can assist with network testing and troubleshooting. Actually, I’ve been thinking about this particular project for years. There are some specific capabilities I have never been able to find in the wild, at least in an open-source, free format. These capabilities are complex, but center on the ability to deploy “non-centralized” network testing agents (apps) that can test various paths between network endpoints, based on WAN requirements for services that require certain protocols and ports to be accessed over firewalls, routers, etc.
The capability should have a user interface that allows the user to specify endpoints based on TCP, UDP/unicast, and UDP/multicast (IPv4 and IPv6).
The capability should not rely on a centralized controller (which would require the very network infrastructure we’re testing to be pre-tested – which doesn’t make sense). Therefore, each app instance should act as an independent path configuration, controller, and reporting capability.
The configuration interface should be a user-friendly GUI that allows the specification of endpoints, starting/stopping of communications, and reporting of other app instances and the “full-mesh” status of all paths between nodes.
The capability should have the ability to report path status even when a “direct” line of communication fails between two instances. This can be achieved by indirect communication via app instances relaying information. Every path that can be established serves as a potential channel for conveying path status information.
The capability app instances should be configurable to allow the propagation of new paths (connections) or to limit propagation. This is basically the ability to re-configure remote app instances from any local app instance.
I don’t personally think a “headless” (non-GUI service) mode will be necessary at first, but this should be considered in the design since I have seen use cases where similar low-level network testing tools require this for various reasons.
Some background… I’ve worked with similar tools that provide parts of this capability. The most noteworthy is a tool developed originally by GBL for TRMC/JMETC called “ClearPath” that is currently in use for JMETC support. Clearpath was written in Java, and focusses exclusively on IPv4 UDP/multicast testing (configured at each endpoint via test config files). Responsibility for the maintenance was transferred to a government development team (or more accurately a contracting team working on behalf of the government). Unfortunately, its development within/for government use limited its visibility and distribution to a small community. There is also a push to convert older Java apps to technologies that do not require a JVM within certain parts of the DoD. Without getting into the politics of the situation, it looks like Clearpath will get abandoned in favor of expanding another network testing tool that requires a centralized controller and various network paths and apps to be pre-established. I’m hoping this situation resolves itself but I’m not holding my breath.
Anyway, the clearpath fiasco, along with a long history of supporting network events, got me thinking again about the lack of these kinds of tools in the open source community. I think this is driven by the fact that some commercial tools already exist (but I’ve never found anything that would exactly meet the requirements from my perspective). I also think that the added complexity of DoD WANs push the need to build things like clearpath in the first place. For example, we deal with a lot of encryption equipment that introduces certain limitations and additional challenges – and even changes how multicast is routed on a WAN. There are also other “complications” arising from security-related requirements, differences in policies between services, various interpretations and issues related to security implementation guidelines, etc. I won’t go into detail about any of these things, but hopefully you get the idea that there are a lot of issues.
With all that in mind, I started thinking of what to call this little side-project. I came up with “Circucast”. I originally wanted to combine “circle” with the “cast” part of unicast and multicast (I don’t think broadcast is something I’ll focus on). The “circle” is in reference to how I was envisioning the indirect communication to provide a more complete picture of open/closed paths across an entire complex network/endpoint plan. But “circ” could be short for “circuit”, which works just as well (maybe better). Anyway, I had to name the project something. I didn’t see this name coming up for anything in any Internet searches and I registered the domain name circucast.com in case this develops into anything useful (there’s not an associated website yet, and I don’t know if I’ll need one).
I started experimenting in a private github repo with a cmake based project using C++, a Qt based GUI, and the Qt Network library. So far I don’t have anything functional, just a GUI mock-up, some simple Qt Network library experiments, and a lot of ideas. I’ll try to formalize those ideas and post some design docs, etc. as time permits. I’ll leave the repo private for now (until I have something functional to share). However, if anyone is interested in contributing-to this project, testing the app when it’s ready, or has a use case where they might use “something like this” (which I’ll begin to formally define better), let me know!
The only thing that might kill/delay this project is if I simply don’t have any time to work on it, or if another project gets developed that does exactly what I’m describing. It’s possible that the government contracting team I described above might take this approach, but it sounds like the original clearpath use case will no longer be supported and the replacement technology will require more complex network capabilities to be in place before the capability can be used (still baffles me – so maybe this approach will be reconsidered).
I worked on this a little this evening. Here’s what the GUI looks like so far…
Under the hood, I chose to have a more flexible model where I’ll eventually be able to add TCP and UDP/unicast classes. For now, I just worked on the sending side of the UDP/multicast classes and verified the packets using Wireshark. I have not implemented anything on the receive side yet.
The design uses a “NetworkPath” class I built to hold generic to/from information for any kind of network path. Instances of this class are kept in a map, using a “toString()” function as a key for the GUI list widget (there’s probably a better way to do this – so I might come back to this). When the user clicks the “Start sending and receiving” button, the app iterates over an internal list of NetworkPath objects (stored as shared pointers in a vector – i.e. a dynamically growing array). For each NetworkPath that is a UDP/multicast path (all of them right now), the app creates a MulticastSender object (another class I built) to manage a single connection. Each of the connections operates in their own thread. This design simplifies the NetworkPath and MulticastSender classes since each MulticastSender only needs to manage a single path. Also, when the “stop sending and receiving” button is clicked, the app simply needs to clear the vector of shared MulticastSender pointers. By using C++ shared_ptr “smart pointers”, each objects destructor is called when the container is cleared.
This is also giving me an opportunity to work with Qt-v6 for the first time (I’ve used Qt-v5 quite a bit, but this is my first go round with Qt-v6). Additionally, this is giving me an opportunity to work with Visual Studio 2022 (community edition) for the first time (I’ve used Visual Studio 2019 professional editions quite a bit, but this is my first go round with Visual Studio 2022). In my day job (DoD contracting work), we’re usually two or three years behind the latest commercial software releases for numerous sad reasons. So these side projects are a good way to play around with more up to date tools.
I still have this in a private repo until I have time to add some receive side functionality, test some more, and clean up the code a little. Other things to think about when I get back to this…
- Saving/loading configuration
- Exporting test results
- Identification of app instances (will probably use a UUID value and/or user set value
- Configuration of send rate and packet size
- Remote propagation of configuration (probably with some kind of security token)
- Embedding system configuration and performance information in the packets
- Installation/packaging (I’ll probably use wix for this on Windows and rpm files for RHEL, Rocky, etc.). I’ve never messed with ubuntu packaging, so I’ll probably use this project as a backdrop for experimentation for Ubuntu/Debian as well.
I started a more permanent page here to post status/updates for circucast: https://www.geohub.com/circucast/. The domains circucast.com/net/org also redirect to this page.