Re: capture and inject device capabilities in libpcap

[Guy Harris <gharris () sonic net>]

On Nov 24, 2024, at 12:41 PM, Denis Ovsienko <denis () ovsienko info> wrote:

> 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.

My inclination is to have libpcap supply devices regardless of whether they have no-capture or no-inject set, and have 
the caller choose what to show.

That way, it can be changed at the application level if the existing application behavior is an issue. For example, a 
sniffer could start out not showing no-capture devices and, if people ask why the XXX interface isn't showing up, and 
it turns out that it's a device that doesn't support capture, it can provide some way of letting the user know that 
such and such a device doesn't support capturing.

> 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

They both look good to me (modulo tweaking of the names in tcpdump and possibly having it ignore the "no inject" flag".

> One other disputable point is the choice of names for the flags -- I
> suspect better naming is possible.

API names or UI names?  For the UI names, I might use "capture not supported" and "packet injection not supported", 
although tcpdump isn't a network tester that injects traffic, so it needn't report that flag at all. The same applies 
to *Shark.
_______________________________________________
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