The "null" capture module type leaves certain capture devices enabled.

[infrastation]

Steps to reproduce:

1. ./configure --with-pcap=null
2. Link tcpdump with the resulting libpcap.
3. Run tcpdump -D and see:

   1.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
   2.nflog (Linux netfilter log (NFLOG) interface) [none]
   3.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
   4.dbus-system (D-Bus system bus) [none]
   5.dbus-session (D-Bus session bus) [none]
   

4. Run ldd tcpdump and see libdbus-1.so.3, libsystemd.so.0 etc., also libibverbs if the development package is installed. There is no obvious way to disable linking with libibverbs.

If the intended purpose of the "null" module is to produce a build of libpcap that can read and write savefiles, as well as compile filters, but otherwise stays isolated from all packet capture facilities (and the associated dependencies), this is currently broken.

[guyharris]

Perhaps we should have a --with-capture option, defaulting to "yes" (and failing if we don't have support for a capture mechanism for the platform), with --without-capture disabling all capture support, instead of having a selectable "null" capture mechanism.

[infrastation]

That's a possibility. For reference, my use case is compiling filtertest and tcpdump for BPF Exam, in which case the executables never run as root and never do any packet capture, and still by default fail to run on the server because my development environment has libibverbs development packahe installed, but the server does not have even the runtime package. So I thought using the "null" module instead of removing the packages each time I need to compile an executable for the server would work better, but it does not.

[guyharris]

Another use case might be "I want a build of tcpdump that can read and print captures/write out filtered captures/etc. but that can't capture traffic" (people have wanted builds of Wireshark of that sort in the past).

[infrastation]

The "null" module was introduced in libpcap 0.1 in 1995:

- Add pcap-null.c which allows offline use of libpcap on systems that
  don't support live package capture. This feature resulting from a
  request from Jan van Oorschot [...]

So there was a use case back then, although it is difficult to tell what exactly it was and whether it still exists and how well the current implementation solves it.

Also the problem space has evolved over years due to the introduction of D-Bus etc., also the set of supported OSes has been changing and libpcap code has been evolving, and presently every known supported OS has means to enumerate regular network interfaces and to capture packets on one of them (except maybe Windows without Npcap, which could be another use case?). All of this could explain why nobody complained that the "null" module is "null" only in the regular network interface space.

I guess it would not be wrong to clarify that "live packet capture" means all device types, not just regular network interfaces, and to make the "null" module a case of xxx_only, which disables everything else. In this case --with-pcap=null would mean exactly the --without-capture above, and the existing implicit "auto-detect by default" would mean the same as --with-capture above. Would it make sense?

In any case, libibverbs support needs means to be disabled manually.

[guyharris]

The "null" module was introduced in libpcap 0.1 in 1995:
...
So there was a use case back then, although it is difficult to tell what exactly it was and whether it still exists and how well the current implementation solves it.

The module mechanism, and the ability to capture on things that aren't regular network interfaces, weren't in libpcap in 1995, and a lot more UN*Xes, many of which didn't have capture mechanisms, did exist back then.

The usage case was for those UN*Xes that didn't have capture mechanisms. Currently, the only non-dead UN*Xes are:

• Linux;
• FreeBSD/NetBSD/OpenBSD/DragonFly BSD/CupertinoBSD (Darwin) and derivatives thereof;
• Solaris > Solaris 1;
• AIX;
• HP-UX (although it's not being ported to any non-dead instruction sets);
• the Hurd;

all of which have capture mechanisms that current libpcap supports.

So that use case doesn't apply to them. It could potentially apply to non-UN*Xes, although we support at least two of them, Windows (along with the Npcap driver and library) and Haiku, so I'm not sure how much that use case matters even there.

It would still work for any such OSes, as long as they don't happen to support any of the capture modules we provide.

(There's also the remote capture support, although, for now, that's enabled by default only for Windows.)

except maybe Windows without Npcap, which could be another use case?

I'd see that as the same use case as UN*Xes lacking a capture mechanism. (I guess it might be possible to use Event Tracing for Windows, but I don't know offhand how difficult that would be or whether its performance would be adequate.)

The only modules we support on Windows are 1) AirPcap (for which we're dropping support in 1.11, as the hardware isn't supported and is unavailable from Riverbed), 2) TurboCap (ditto), and DAG cards.

Issue #1016 was filed for that; we fixed it in d7f44c5, which changed the autoconf and CMake configuration mechanisms so that, if no supported capture mechanism is found, we fail with a "no capture mechanism found, try specifying null in order to get a libpcap that doesn't capture but that reads and writes capture files" mechanism rather than defaulting to null.

Also the problem space has evolved over years due to the introduction of D-Bus etc.,

I.e., we now have modules to support capturing on things other than regular network interfaces. I think the first of those were Linux-specific mechanisms, but D-Bus isn't Linux-specific, and it may have been the first of those that wasn't.

The main change there is that it's now possible to build a libpcap that doesn't capture on regular network interfaces, by explicitly specifying the "null" capture mechanism, but that does support capturing on other devices.

I guess it would not be wrong to clarify that "live packet capture" means all device types, not just regular network interfaces, and to make the "null" module a case of xxx_only, which disables everything else.

Yes. I'd also have both "none" and "no" as aliases, the former as it better describes what that means ("no capture mechanism") and the latter as it would be how you make --without-pcap work.

In this case --with-pcap=null would mean exactly the --without-capture above, and the existing implicit "auto-detect by default" would mean the same as --with-capture above. Would it make sense?

I'd say it does.

In any case, libibverbs support needs means to be disabled manually.

Another mechanism might be something to explicitly disable individual capture modules, rather than just disabling all capture support, e.g. "I want to build a libpcap that will work on Frobozz Linux 12.x, regardless of whether it has libxyzzy installed", so you disable the capture mechanism(s) that require libxyzzy, but you want all mechanisms that don't require additional non-default libraries (including PF_PACKET sockets for regular interfaces) supported.

[infrastation]

Thank you, let me think about it. None of this problem space seems to be urgent (my use case occurs a few times a year and I can tolerate the inconvenience).