nDPI: Deep Packet Inspection Library
/nDPI
nDPI is ntop's open-source library for identifying application protocols inside network traffic, licensed LGPL-3.0. It's a C library meant to be linked into your own code, not a finished application, and its own README admits detection isn't guaranteed error-free. Reach for it if you're building a monitoring or blocking tool in C; skip it if you want a ready-made traffic dashboard, since that role belongs to ntopng or nProbe cento.
Understanding nDPI: A Deep Packet Inspection Library
nDPI, built and maintained by ntop, is a deep-packet inspection library written in C, released under the LGPLv3 license. It classifies network traffic by protocol and ships with a procedure for adding new dissectors โ register a protocol ID, write a detection function under src/lib/protocols/, and wire it into the flow-state structs. ntopng and nProbe cento embed nDPI to act on that classification.
Core Capabilities for Network Protocol Detection
- โDetects application protocols inside network traffic through deep packet inspection, matching the repo's own topics (cybersecurity, deep-packet-inspection, dpi, network, traffic-analysis).
- โCompiles as a standalone library with the --with-only-libndpi flag, skipping the bundled example tools and tests when you only need the detection engine.
- โSupports out-of-tree builds (mkdir build && cd build && ../configure && make) alongside the standard in-tree ./autogen.sh && ./configure && make flow.
- โShips three separate test entry points: ./tests/do.sh for PCAP diff regression checks, ./tests/do-unit.sh for unit tests, and ./tests/do-dga.sh for DGA (domain-generation-algorithm) detection, all runnable together via make check.
- โDocuments a numbered, twelve-step procedure for adding a new protocol dissector, from registering a protocol ID in ndpi_protocol_ids.h through updating doc/protocols.rst.
- โCan build with optional nBPF support by cloning ntop's separate PF_RING project, needed to run the complete unit-test suite with PCRE2 enabled.
- โBuilds on Linux, FreeBSD, macOS, and Windows (via MSYS2, Mingw-w64, or Visual Studio's windows/nDPI.sln), with Windows requiring npcap in WinPcap compatibility mode.
- โBacked by a peer-reviewed 2014 IWCMC paper by Deri et al. on high-speed packet inspection, plus a public trail of conference talks from 2017 through 2025.
Compiling and Installing nDPI Across Platforms
Compiling nDPI from source starts with ./autogen.sh && ./configure, followed by make; if the build fails on croaring.c, reconfigure with --enable-old-croaring. Adding --with-only-libndpi to configure builds just the library, skipping the bundled tools and tests, and the project also supports out-of-tree builds (mkdir build && cd build && ../configure && make). Compilation needs the standard GNU toolchain (autoconf, bison, flex, automake, libtool, pkg-config, and gettext) plus gcc or Clang. On Debian/Ubuntu that pulls in dev packages including libjson-c-dev, libnuma-dev, libpcap-dev, librrd-dev, libmaxminddb-dev, and libpcre2-dev, while Arch Linux and FreeBSD each get their own package list in the README (FreeBSD uses gmake, not make). macOS installs the same dependencies through Homebrew. Windows has three build paths: MSYS2, Mingw-w64, or Visual Studio via windows/nDPI.sln, and all three require npcap installed with WinPcap compatibility mode enabled. To run the test suite, use ./tests/do.sh for PCAP regression tests, ./tests/do-unit.sh for unit tests, and ./tests/do-dga.sh for DGA detection tests, or run everything at once with make check.
Integrating nDPI for Traffic Analysis and Blocking
nDPI doesn't block or analyze traffic on its own; it's a library you embed into an application, and the README is explicit that this embedding step is required to act on its output. To block selected traffic, an application calls into nDPI's classification logic during packet processing and then applies its own filtering decision based on the protocol nDPI reports back. ntop's own tools follow this pattern: ntopng and nProbe cento both embed nDPI to turn raw packet streams into protocol-aware monitoring and blocking. If you're extending detection coverage rather than just consuming it, the README also documents a workflow for building the documentation (pip install -r doc/requirements.txt, then make doc, with make doc-view to preview it locally) once you've added or changed a dissector.
Strengths
- โLGPL-3.0 licensing lets you link nDPI into proprietary applications without releasing your own source, unlike GPL-only alternatives.
- โA concrete, step-by-step process exists for adding new protocol dissectors rather than leaving contributors to reverse-engineer the codebase.
- โThree separate test categories (PCAP regression, unit, DGA detection) give some confidence that changes don't silently break existing detections.
- โBuilds cleanly across Linux, FreeBSD, macOS, and Windows, with distro-specific package lists spelled out for Debian/Ubuntu, Arch, and FreeBSD.
- โBacked by a decade of public conference talks and a peer-reviewed paper, so the detection approach isn't undocumented in academic terms.
Important Considerations for nDPI Use
- โณThe README itself disclaims that protocol detection isn't guaranteed error-free or 100% accurate. You're expected to validate results for your own traffic before trusting it in production.
- โณnDPI is a library only; blocking or monitoring traffic requires embedding it into another application like ntopng or nProbe cento, not something it does standalone.
- โณCompiling from source pulls in a GNU toolchain plus libraries like libpcap, json-c, and PCRE2; there's no prebuilt binary distribution mentioned in the README.
- โณAdding a new protocol touches at least six files and, for full unit-test coverage, requires cloning and building ntop's separate PF_RING/nBPF project alongside it.
- โณThe nDPI name carries registered trademark status in both the US and EU, according to the README, worth knowing if you plan to redistribute or rebrand a product built on it.
Projects Related to nDPI
nDPI Frequently Asked Questions
nDPI is released under the GNU Lesser General Public License version 3 (LGPL-3.0), which lets you link it into proprietary software without open-sourcing your own code.
nDPI itself is a library, not a standalone blocking tool, so blocking requires embedding it into an application; the README points to ntopng and nProbe cento as examples that use nDPI this way to block selected traffic.
nDPI's own README is explicit that accuracy isn't guaranteed: it states the project cannot promise its software is error-free or 100% accurate at identifying protocols, so results should be validated for your specific traffic.
nDPI compiles on Linux (with documented steps for Debian/Ubuntu and Arch), FreeBSD (using gmake instead of make), macOS via Homebrew, and Windows through MSYS2, Mingw-w64, or Visual Studio, with Windows builds needing npcap in WinPcap compatibility mode.
Adding a protocol to nDPI means registering a unique ID in ndpi_protocol_ids.h, writing the detection code under src/lib/protocols/, adding any flow-state variables to the relevant struct in ndpi_typedefs.h, wiring the search function into ndpi_private.h, and updating doc/protocols.rst, per the README's twelve-step procedure.
nDPI's README states that the nDPI name holds registered trademark status in both the United States and the European Union.
The problem it solves
Ports lie. A developer building a network-monitoring or security tool needs to know what's actually running over a connection, not just which port it's using, since ports get reused or deliberately obfuscated by applications avoiding filters. Writing detection logic for each protocol from scratch means tracking every protocol's quirks yourself, indefinitely. nDPI's README points at this gap directly: a maintained set of protocol dissectors plus a defined procedure for adding new ones, so a project doesn't have to build that detection layer alone from zero.
Best use cases
- โขEmbedding protocol detection into a custom C network-monitoring or security tool instead of writing a dissector from scratch.
- โขBuilding a traffic-blocking feature on top of nDPI's classification output, the way ntopng and nProbe cento do.
- โขExtending nDPI with a dissector for an internal or proprietary protocol it doesn't already recognize, following the README's step-by-step process.
- โขAcademic or research work on network traffic classification, citing the project's 2014 IWCMC paper as prior art.
Who should try it โ and who should skip
Try nDPI if you're writing a network-monitoring, security, or traffic-shaping tool in C (or something that can link a C library) and need protocol classification without hand-rolling dissectors for every protocol you care about. It also suits researchers who want a documented, citable DPI implementation to build on or compare against. Skip it if you want a finished application: nDPI has no UI and no standalone blocking mode, so you'd need to either embed it yourself or use ntopng/nProbe cento, which already do that integration work.
Related repositories
Is nDPI worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of nDPI.