SharpPcap for .NET Packet Capture: APIs and Limits

Why SharpPcap Exists in the .NET Capture Stack

SharpPcap addresses a fragmentation problem in cross-platform network programming. Packet capture on Windows can involve Npcap, WinDivert, or the Npcap extensions to libpcap, while Linux depends on libpcap. A managed .NET application that calls those interfaces directly would need platform-specific code and native interop. SharpPcap places a common C# API over those mechanisms and also treats pcap and pcap-ng capture files as devices.

The intended audience is developers building .NET applications that inspect live network traffic, collect packets for later analysis, or process existing capture files. The README also lists live device enumeration and statistics, so the library is not limited to a one-time dump. It supports both .NET Core 3 and .NET Framework, according to the README, although the example syntax uses features such as `using var` that should be checked against the selected target framework.

SharpPcap handles acquisition rather than protocol dissection. The README directs users to Packet.Net for packet dissection and creation. That division is important: applications can use SharpPcap to obtain bytes from an interface or file without treating this repository as a complete network analysis toolkit. It is a reasonable choice when the capture boundary must remain consistent across C# applications, but it is not a replacement for protocol parsing, flow analysis, or application-level inspection.

SharpPcap's Device and Packet Data Flow

The central abstraction is a device. The documented examples use `CaptureDeviceList.Instance` to enumerate available devices, `LibPcapLiveDeviceList` for a live libpcap-backed device, `CaptureFileReaderDevice` for a saved capture, and `CaptureFileWriterDevice` for output. This gives callers a similar acquisition path for network interfaces and offline files, although concrete operations differ between them.

For live capture, the documented sequence is to obtain a device, call `Open()`, subscribe to `OnPacketArrival`, and start capture with `StartCapture()`. Each event receives a `PacketCapture`. In version 6, packet data is exposed through `ReadOnlySpan<>`, and `PacketCapture.GetPacket()` converts that data to `RawCapture` when an object representation is needed. The README says this design avoids allocation and copying inside SharpPcap. It is especially relevant when packets are written to storage for later processing, because immediate forwarding can avoid creating a managed packet object for every arrival.

Offline capture follows a different execution model. `CaptureFileReaderDevice` is opened and then driven by `Capture()`. Writer devices expose `Write(bytes)`, with the documented example accepting a four-byte array. File support includes pcap and pcap-ng where the backend supports them: libpcap 1.1.0 or later, or Npcap on Windows.

Native library resolution is handled through `NativeLibrary`. The README specifically says SharpPcap can load libpcap on Linux distributions that have only a versioned `libpcap.so.X.Y` file and lack the conventional `libpcap.so` symlink. This is a practical deployment concern because a managed wrapper still needs a discoverable native backend.

Backend Constraints for Windows, Linux, and macOS

Cross-platform here means that the same managed library can support several operating systems, not that capture works without platform components. Linux support is based on libpcap. Windows support includes Npcap, its former WinPcap extension path, and WinDivert. The migration notes also state that recent Npcap releases include newer libpcap versions that provide almost all functionality of Npcap's native APIs, with statistics identified as a remaining gap at that point.

macOS has a more specific constraint. The README states that macOS 11.1 lacks libpcap with `pcap_open`. That warning matters during deployment planning because the broad claim of macOS support should not be read as identical native API availability across macOS releases. The documentation does not provide a separate workaround or setup procedure for that limitation.

The Windows example uses `LibPcapLiveDeviceList`, but the presence of WinDivert topics and backend support does not mean every operation is available through every backend. Filter support is documented as cross-platform, yet native capabilities can still differ by platform. `NpcapRemoteCapture` and `WinpkFilterExample` appear as example projects, but the cleaned README does not explain their prerequisites. Developers should therefore verify the backend required by a specific example instead of assuming that its code is portable without configuration.

SharpPcap's abstraction reduces branching in managed application code. It does not remove the need to decide which native capture mechanism exists and is usable on each deployment host.

Installing SharpPcap and Starting a First File Read

The README says that SharpPcap is released through NuGet and links to the `SharpPcap` package. It does not provide an installation command, package version declaration, or platform setup tutorial, so this review does not invent a `dotnet` or package manager command. It also does not document installation steps for Npcap, WinDivert, or macOS native dependencies. Those responsibilities must be checked against the selected backend and target system.

A practical first use can begin with an existing capture file, using the exact reader pattern documented in the README:

using var device = new CaptureFileReaderDevice("filename.pcap");
device.Open();
device.OnPacketArrival += Device_OnPacketArrival;
device.Capture();

The application also needs the documented event handler that prints the packet received in each `PacketCapture`:

void Device_OnPacketArrival(object s, PacketCapture e)
{
    Console.WriteLine(e.GetPacket());
}

With `filename.pcap` replaced by a readable capture file, `Capture()` drives packet delivery through the registered handler. This path avoids selecting a live interface, so it gives a new user a concrete way to exercise device opening and packet reading. The README does not describe the expected terminal output format because packet representations can vary, but the handler's documented output is `e.GetPacket()`.

For live traffic, the repository documents `LibPcapLiveDeviceList`, `Open()`, `OnPacketArrival`, and `StartCapture()`. That path requires an available capture device and its native backend. The `Examples/` directory contains fuller projects for basic capture, filters, statistics, background queues, packet manipulation, ARP resolution, sending packets, Wake on LAN, remote Npcap capture, and other tasks. Those projects are the documented starting point for adapting the README examples into a full application.

Allocation Avoidance, Filters, and Advanced Capture Work

The most distinctive design choice in version 6 is the use of `ReadOnlySpan<>`. The migration guide says conversion through `PacketCapture.GetPacket()` produces a `RawCapture` for callers that need a managed object. Applications that only dump packets can therefore avoid the allocation and copy associated with creating those objects. The README includes a possible performance comparison, but this review treats it as a documented claim rather than an independently measured result.

Capture filters use Berkeley Packet Filters. Example projects include `Example5.PcapFilter` and `MultipleFiltersOnDevice`, indicating that filter configuration has dedicated examples beyond basic receipt. The cleaned documentation does not show filter strings or API calls, so it would be unsafe to manufacture one. The direct reference is the corresponding project in `Examples/`.

The repository layout also indicates several areas beyond a basic callback loop. `Example10.SendQueue` and `QueuingPacketsForBackgroundProcessing` point to buffered or background processing patterns. `Example11.Statistics` covers the documented statistics facility. `Example12.PacketManipulation` addresses packet work, although the README sends full dissection and creation to Packet.Net. `NpcapRemoteCapture` indicates a distinct remote-capture scenario rather than merely another local interface list.

These examples matter because SharpPcap has multiple device modes and backends. A callback-based read loop is only one operating pattern. Send queues, filters, statistics, remote capture, and file conversion can have different setup and platform requirements. Copying a basic snippet without checking the relevant example would skip the parts that establish those distinctions.

SharpPcap 6 Migration, Licensing, and Maintenance Boundaries

SharpPcap 6 contains API-breaking changes from 5.x. Devices implement `IDisposable`, so callers replace ordinary variable declarations with `using` declarations and remove explicit `Close()` calls. `OpenFlags` becomes `DeviceModes`, `DeviceMode` becomes `DeviceModes`, and several `Open()` overloads are consolidated through default parameters. `NpcapDevice` is replaced by `LibPcapLiveDevice` in the migration guidance. Packet delivery also changes through `PacketCapture` and `ReadOnlySpan<>`. These are source-level changes that affect types, lifecycle management, and callback handling.

The migration notes also say Mono `DllMap` support was removed because `NativeLibrary` is used instead. This may simplify native resolution on supported runtimes, but it narrows compatibility assumptions for applications built around the older Mono mapping mechanism. The README provides a summary list rather than a complete migration guide, so upgrading requires reviewing call sites as well as the listed API changes.

The repository is not archived, and the last push was on 2026-10-13. However, the release information shown in the repository lists the latest release as pointing readers to NuGet on 2020-04-17, while named SharpPcap releases include versions from 2017 and 2015. Repository activity and published package history should therefore be checked separately rather than treating a recent push as proof of a particular package release.

License information is marked unknown in the repository metadata, but the repository contains a `LICENSES/` directory and `REUSE.toml`. The README states that internal modifications are expected to follow the library's license. The package, repository license files, and dependency terms should be reviewed directly before redistribution or commercial integration. No legal conclusion can be drawn from the directory names alone.

Direct Native APIs and Packet.Net as Alternatives

The clearest alternative is direct use of the platform's native capture APIs. A program can call libpcap on Linux, Npcap on Windows, or WinDivert without a SharpPcap abstraction layer. That approach avoids the wrapper's API version changes and gives the application direct control over native behavior. The tradeoff is explicit: platform-specific loading, interop, callbacks, and device lifecycle must be handled in application code, while SharpPcap centralizes those concerns in C#.

Packet.Net is a different alternative rather than a direct substitute. The README positions it as the project for packet dissection and creation, whereas SharpPcap covers capture devices, packet acquisition, filters, statistics, and capture-file writing. An application may use SharpPcap to obtain packets and Packet.Net to interpret them. A program that already receives structured packet data may not need SharpPcap's device and native-library layer.

Direct native integration is the better fit when exact control over backend-specific APIs is more important than a shared managed surface. SharpPcap is the better fit when C# code must span operating systems and the project values `ReadOnlySpan<>` packet delivery. The choice comes down to whether abstraction and managed consistency are worth accepting SharpPcap's native dependencies and version-specific API surface.

Editorial conclusion

SharpPcap suits C# developers who need one managed interface over libpcap, Npcap, WinDivert, and capture files, especially when allocation-conscious packet handling matters. It is less suitable for code that must remain portable without native capture software or for projects unable to absorb the 5.x to 6.x API changes. Before adoption, verify the current package and license on NuGet, confirm the required native backend for each target operating system, and compile the relevant Examples project against the intended SharpPcap version.

Frequently asked questions

Official sources

1. dotpcap/sharppcap on GitHub
2. Issues
3. README
4. Releases