OpenTrace puts NextTrace behind a WPF, GTK and macOS window
Open Source Visualized Route Tracing Tool for macOS, Windows, and Linux.
At a glance
- What is it?
- A C# front end that hands every measurement to the NextTrace executable while owning the window, the parameter entry and the platform packaging. What to check before building is which backend binary sits next to it, because the MTR and token features ask for two different NextTrace versions.
- Who is it for?
- OpenTrace suits people who want NextTrace output in a real window on Windows, Linux or macOS and would rather not read hop tables in a terminal. Check the backend floor before you start, because native MTR wants NextTrace v1.5.2 or newer while automatic token setup wants v1.7.0 or newer, and the fallback between them is silent.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 18 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- Archeb/opentrace4,492 ★ · +45
| Repository | 2026-09-23 | 2026-11-14 |
|---|---|---|
| Archeb/opentrace | 4.4k | 4.5k |
45 Stars in the last 52 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
NextTrace does the walking, the three backends only draw it
OpenTrace contains no tracer of its own. Every hop it draws is measured by NextTrace, the NTrace-core project the repository credits as its backend, so what the C# codebase owns is parameter entry, result rendering and platform packaging rather than packet capture or path probing. Three native backends carry that interface: WPF on Windows, GTK on Linux and a native macOS app bundle.
The feature list adds custom DNS resolvers over plain DNS and DoH, support for a local .MMDB database, MTR mode, a command line entry that starts a trace, six translated interfaces and Cloudflare verification that sets up a NextTrace API v4 token automatically. Anything about how a probe is sent, or which router answers, is decided by a separate executable that a self-built copy has to supply.
net48 on Windows, net8.0 bundled everywhere else
The documented builds split into two different runtime models, and the commands make that visible. Prerequisite work is the .NET 8 SDK plus GTK 3 on Linux or the Xcode Command Line Tools on macOS, while an MSIX bundle needs 64-bit Windows, PowerShell and the Windows 10/11 SDK with `MakeAppx.exe`. Commands run from the repository root, and building on the target operating system is the stated practice. Restore happens once, then each platform gets its own line.
dotnet restore OpenTrace.csprojdotnet build OpenTrace.csproj --runtime win-x64 --configuration Release --no-self-contained -f net48
dotnet build OpenTrace.csproj --runtime win-arm64 --configuration Release --no-self-contained -f net481
dotnet build OpenTrace.csproj --runtime linux-x64 --configuration Release --self-contained -f net8.0
dotnet build OpenTrace.csproj --runtime linux-arm64 --configuration Release --self-contained -f net8.0
dotnet build OpenTrace.csproj --runtime osx-x64 --configuration Release --self-contained -f net8.0
dotnet build OpenTrace.csproj --runtime osx-arm64 --configuration Release --self-contained -f net8.0Windows is the outlier. Both Windows lines pass `--no-self-contained` against `net48` and `net481`, so those outputs expect a .NET Framework already installed, whereas the Linux and macOS binaries carry their runtime with them. Every platform writes to its own output tree.
bin/Wpf/Release/net48/win-x64
bin/Wpf/Release/net481/win-arm64
bin/Gtk/Release/net8.0/<runtime>
bin/Mac64/Release/net8.0/<runtime>/OpenTrace.appMTR falls back silently when NextTrace is older
MTR, short for My Traceroute, is the one feature whose behaviour is decided by the age of the backend binary rather than by OpenTrace itself. With NextTrace v1.5.2 or newer the app uses the native MTR implementation from NextTrace; when that build is unavailable it falls back to a compatibility implementation, and the feature list states that the switch happens silently. Nothing on screen distinguishes which of the two produced a run.
A second version floor sits in the same list and the two do not line up. Automatic setup for NextTrace API v4 tokens through Cloudflare verification requires NextTrace v1.7.0 or newer, so a self-compiled setup holding a NextTrace build from v1.5.2 up to v1.7.0 gets native MTR and no token automation at all. Version 1.5.2 is also the value the Store packaging script is invoked with, which is precisely the confusion to avoid when checking what is installed.
Npcap by hand, WinDivert inside the Store bundle
TCP and UDP traceroute on Windows needs a capture driver, and this project handles that two different ways depending on how you obtained it. The usage notes tell a Windows user to download and install Npcap. The Store packaging script instead downloads pinned and SHA256-verified NextTrace payloads together with the required WinDivert files, prepares package artwork, builds x64 and ARM64 and merges them into one bundle.
.\scripts\Build-StorePackage.ps1 -Version 1.5.2.0The result is `artifacts\store\OpenTrace_1.5.2.0_x64_arm64.msixbundle`, which Partner Center accepts unsigned, while the architecture-specific packages under `artifacts\store\packages` must not be uploaded. A local certificate is needed only for the sideload-testing variant.
.\scripts\Build-SignedStorePackage.ps1 -Version 1.5.2.0The asymmetry is worth naming: pinned payloads and checksums guard the automated path, whereas the manual path asks you to place a NextTrace build beside the executable yourself.
A self-built copy has to find its own backend
A copy you compiled yourself carries a second half of the installation. NextTrace must be downloaded for your system architecture from the NextTrace project, then placed in the OpenTrace directory or in a directory on the PATH environment variable. You can put it anywhere else and specify the path manually, which is the recommended arrangement for macOS users. When a redistributable archive is assembled, the matching NextTrace executable goes beside OpenTrace, in `OpenTrace.app/Contents/MacOS` on macOS, or the application settings can select an external one at runtime.
No error text is documented for a missing or misplaced NextTrace, so a self-built copy that fails to trace leaves you without a stated diagnosis. macOS adds another gate: signing, notarization and DMG creation require Apple developer credentials, with that process written down in a workflow file under `.github/workflows`.
Six translated labels over one backend vocabulary
The interface ships in English, Chinese, French, Spanish, Japanese and Russian, and its parameter descriptions are meant to be read rather than guessed. Six translations cover a single backend vocabulary, so a label can promise an option that the NextTrace build sitting on your disk does not accept. Custom resolvers are limited to DNS and DoH, and a local .MMDB database is supported.
Nothing beyond that list is promised. Unfinished work goes through a feature request form rather than a roadmap, with no stated timeline attached. Unstable builds are offered separately as well: the latest beta for your architecture is downloadable from the Actions page, and the README warns that such a build may contain bugs or vulnerabilities, or may be unstable.
The default branch is dev and two solutions share one root
Cloning gets you the dev branch rather than a shipped line, and the root carries two solution files, `traceroute.sln` and `traceroute-store.sln`, because the Store package is a separate build target with its own scripts. Other top-level folders are `HomePage/`, `UI/`, `Services/`, `Models/`, `Infrastructure/` and `Assets/`, joined by the packaging files `Entitlements.plist`, `Info.plist` and `opentrace.desktop`, plus a `scripts/` directory holding the PowerShell packaging. `OpenTrace.csproj` is the single project file every documented build targets and `Program.cs` is the entry point. A `THIRD-PARTY-NOTICES.md` file sits beside the main project files. The last push landed on 2026-10-27 and the repository is not archived.
Editorial conclusion
OpenTrace suits people who want NextTrace output in a real window on Windows, Linux or macOS and would rather not read hop tables in a terminal. Check the backend floor before you start, because native MTR wants NextTrace v1.5.2 or newer while automatic token setup wants v1.7.0 or newer, and the fallback between them is silent. Self-builders place that binary by hand, so verify what you drop in. The default branch is dev, which makes a local compile a development snapshot.
Frequently asked questions
What backend does OpenTrace use for route tracing?
OpenTrace has no tracer of its own. It uses NextTrace as the backend, and every hop in its window is measured by that separate executable.
Which NextTrace version does OpenTrace need for MTR mode?
Native MTR is used with NextTrace v1.5.2 or newer. When that build is unavailable the app falls back to a compatibility implementation, and the fallback happens silently.
Why do the documented OpenTrace builds for Windows use .NET Framework targets?
The Windows lines target net48 for x64 and net481 for ARM64 and pass --no-self-contained, so their output relies on a .NET Framework already present. Linux and macOS builds target net8.0 with --self-contained.
Does OpenTrace need anything extra on Windows for TCP/UDP traceroute?
Npcap has to be downloaded and installed for a manual Windows install. The Store packaging script takes a different route and fetches pinned, SHA256-verified NextTrace payloads plus the required WinDivert files.
Where can I get OpenTrace, and how do I know a beta build is risky?
It comes from the official website opentrace.app or the repository releases page, with Flathub and the Arch User Repository as extra Linux options. Beta builds for your architecture sit on the Actions page and may contain bugs or vulnerabilities, or may be unstable.
Does a self-compiled OpenTrace include its own tracing binary?
No. You download NextTrace for your architecture and place it in the OpenTrace directory, on PATH, or wherever you point the application settings, and the recommended arrangement on macOS is the manual path.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/archeb-opentrace)Star history chart for your README
[](https://hysenlabs.com/projects/archeb-opentrace)Was this useful?