pcap_compile() support for name files - ethers, hosts, protocols, services, other?

[bubbasnmp]

Is it documented somewhere that pcap_compile() does not support name resolution?

Npcap Development Tutorial
Filtering the traffic

pcap_compile() takes a string containing a high-level Boolean (filter) expression and produces a low-level byte code that can be interpreted by the fileter engine in the packet driver. The syntax of the boolean expression can be found in the Filtering expression syntax section of this documentation. (typo: fileter)

pcap-filter — Npcap API
One example:

Protocol can be a number or one of the names recognized by getprotobyname(3) (as in e.g. `getent(1) protocols'), typically from an entry in /etc/protocols,

Was there a writing filters document that would have covered name resolution?
Purpose of this manual

the section called “Developing software with Npcap” is for programmers who need to use Npcap from an application: it contains information about functions and data structures exported by the Npcap API, a manual for writing packet filters,

Developing software with Npcap

[guyharris]

Is it documented somewhere that pcap_compile() does not support name resolution?

More precisely, that pcap_compile(), on Windows, supports what name resolution the OS's APIs (mostly Winsock APIs) supports.

It appears that Windows does have getprotobyname().

The question in the title of this issue isn't "does pcap_compile() support name resolution", it's "does pcap_compile() support name resolution from files?"

That ends up being "which of the Windows name resolution APIs support name files?" Unfortunately, the getprotbyname() documentation there doesn't say what sources of name -> number mapping data it supports, and Winsock 2 isn't one of the libraries for which Microsoft makes source code available (unlike, say, the Visual C runtime library).

Apparently, at least for name resolution files, the directory on Windows equivalent to /etc on UN*Xes is C:\Windows\System32\drivers\etc, at least on some versions of Windows.

A quick look on my Windows 11 VM indicates that directory has hosts, network, protocol (sic - yes, they removed the plural), and services files. (No rpc file, but they don't ship ONC RPC libraries with the system.)

No ethers, but Windows doesn't have ether_hostton(), so we'd have to fall back on libpcap's fallback version, with the hosts file path perhaps being defined as C:\Windows\System32\drivers\etc\ethers. Users would have to fill in that file themselves, but that's pretty much true of /etc/ethers on most UN*Xes, as the file may exist on a UN*X but , if it does, it's probably either empty or close to empty.

[bubbasnmp]

Thank you! Now where to document this in Wireshark?
Seems that everything works better with escape ("\") character in front of names.

[guyharris]

Thank you! Now where to document this in Wireshark?

Wireshark should perhaps just point to the pcap-filter man page tcpdump.org. That page explicitly notes that it's for tip-of-the-main-branch bleeding-edge libpcap, and points to manual pages for older versions.

Npcap is currently based on libpcap 1.10.x, so that's what applies to Npcap.

Seems that everything works better with escape ("") character in front of names.

That's because the filter language has "reserved words" such as "ip" that are handled at the lexical-analyzer level, and need to be escaped if they're just strings. The pcap-filter man page points this out in, for example, the section on the "ip proto" primitive:

ip proto protocol
True if the packet is an IPv4 packet of protocol type protocol. For this primitive it does not matter whether the IPv4 packet is fragmented or not. Protocol can be a number or one of the names recognized by getprotobyname(3), for example: ah, esp, eigrp (only in Linux with glibc, FreeBSD, NetBSD, DragonFly BSD, macOS, and QNX), icmp, igmp, igrp (only in Haiku and OpenBSD), pim, sctp, tcp, udp or vrrp. Note that most of these example identifiers are also keywords and must be escaped via backslash (). Note that this primitive does not chase the protocol header chain.

Typically getprotobyname(3) parses the /etc/protocols file to translate protocol names to numbers, and the getent protocols command lists the protocols recognized by the function. This is not entirely so in AIX (which does not have the command), Haiku (which has the file at /system/data/network/protocols and does not have the command), on Linux with musl libc (which hard-codes the list of protocols) and on hosts that use a network database to resolve protocol names to numbers (see nsswitch.conf(5)). If a protocol name fails to translate to a number, this version of libpcap will treat the filter expression as invalid.

[bubbasnmp]

Wireshark does point to the correct man page but it is *nix oriented pointing to /etc files.
Somewhere the C:\Windows\System32\drivers\etc path should be documented.

https://www.wireshark.org/docs/man-pages/
pcap-filter - Capture filter syntax

[guyharris]

Wireshark does point to the correct man page but it is *nix oriented pointing to /etc files. Somewhere the C:\Windows\System32\drivers\etc path should be documented.

Yes, as I noted. I'd say this is a libpcap issue; report on its issue list, provide fixes on its pull request list.

[guyharris]

Yes, as I noted.

(And it's also wrong for Haiku.)