Re: capture and inject device capabilities in libpcap

[Denis Ovsienko <denis () ovsienko info>]

On Mon, 18 Nov 2024 12:30:22 -0800
Guy Harris <gharris () sonic net> wrote:

> On Nov 18, 2024, at 11:54 AM, Denis Ovsienko <denis () 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-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s