On Mon, 18 Nov 2024 12:30:22 -0800
Guy Harris <ghar...@sonic.net> wrote:
> On Nov 18, 2024, at 11:54 AM, Denis Ovsienko <de...@ovsienko.info>
> wrote:
>
> > The current approach in libpcap is such that an application at some
> > point tries to activate a device, and if the device does not support
> > capturing packets, pcap_activate() fails with the
> > PCAP_ERROR_CAPTURE_NOTSUP error code. One drawback of this is that
> > the application has no means to tell a capture-capable device
> > without trying to activate it, another is that telling an
> > inject-capable device takes trying to use the device after
> > pcap_activate() succeeds. It would be useful to have a shorter
> > feedback loop for these capabilities.
>
> So "even neither" devices could either not be shown in
> pcap_findalldevs() or be shown with both of the "not supported" flags
> set. One argument for showing it might be that, if the device isn't
> shown, a user might have reason to expect it to be there, and report
> this as "why isn't device XXX not showing up?", which doesn't
> indicate what the problem is, and turns into a question-and-answer
> session, whereas if the device is present, the user will see the
> device, attempt to capture or inject on it, and get a
> "{capturing,injecting} traffic isn't supported on this device" error,
> and if they report *that*, at least it's known what the problem is,
> shortening the Q&A session and getting an answer more quickly.
Likewise, it is disputable whether no-capture devices should appear in
the user-visible list of capture devices with the flag or not appear at
all. After some prototyping the former made a bit more sense to me,
but other people may have different opinions. Anyway, the proof of
concept is available in the following two draft pull requests:
https://github.com/the-tcpdump-group/libpcap/pull/1388
https://github.com/the-tcpdump-group/tcpdump/pull/1246
It results in the following "tcpdump -D" output:
1.enp8s0 [Up, Running, Connected]
2.enp4s0 [Up, Running, Connected]
3.ens5 [Up, Running, Connected]
4.any (Pseudo-device that captures on all interfaces) [Up, Running, NoInject]
5.lo [Up, Running, Loopback]
6.dag0 (alias for dag0:0) [NoInject]
7.dag0:0 (Rx stream 0) [NoInject]
dag0:1 (Tx stream 1) [NoCapture]
8.dag16 (alias for dag16:0) [NoInject]
9.dag16:0 (Rx stream 0) [NoInject]
dag16:1 (Tx stream 1) [NoCapture]
10.dag17 (alias for dag17:0) [NoInject]
11.dag17:0 (Rx stream 0) [NoInject]
dag17:1 (Tx stream 1) [NoCapture]
12.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless, NoInject]
13.nflog (Linux netfilter log (NFLOG) interface) [NoInject]
14.nfqueue (Linux netfilter queue (NFQUEUE) interface) [NoInject]
One other disputable point is the choice of names for the flags -- I
suspect better naming is possible.
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
