On Nov 24, 2024, at 12:41 PM, Denis Ovsienko <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
