Feature proposal: notification of new/deleted interfaces via event/handle

[dmiller-nmap]

At the time NPF_AttachAdapter() finishes, the adapter should be available for capturing. Some mechanism by which to notify the application that a new adapter is available - or that an adapter has disappeared - might be useful; Wireshark could use it, for example, to update its list of adapters (it already does so on macOS, *BSD, and Linux).

A simple event handle would suffice, although all the UN*X platforms on which Wireshark does that provide separate "new interface" and "interface disappeared" indications, and provides the name of the interface - Wireshark doesn't currently use that for new interfaces, but it does use that for deleted interfaces. If Npcap could provide that, it'd fit in with Wireshark (and with any future libpcap platform-independent API for interface list change notifications).

Wireshark would use this in capture/iface_monitor.c. That file defines routines:

• iface_mon_start() - that takes a pointer to a callback routine, and starts the monitoring process;

• iface_mon_stop() - that stops the monitoring process;

• iface_mon_get_sock() - that gets the a UNIX file descriptor for the socket used for monitoring, so that it can be checked in Wireshark's event loop;

• iface_mon_event() - that is the routine to call from the event loop when events are available on the socket;

• iface_mon_enable() - takes a flag to indicate whether to temporarily enable or disable the monitoring process, in order to work around a Linux issue.

For Npcap, iface_mon_get_sock() would be replaced by, for example, iface_mon_get_handle(), which would return a HANDLE, which would be provided to Qt (the GUI toolkit for Wireshark) to wait for an event. It looks as if Qt's QWinEventNotifier (https://doc.qt.io/qt-6/qwineventnotifier.html) could be used to wait on the HANDLE. Qt's Windows main loop calls MsgWaitForMultipleObjectsEx() with a null pHandles pointer, so it doesn't wait for the HANDLE, but the QWinEventNotifier code calls SetThreadpoolWait() on the handle, so I guess there's a special thread that does the waiting, with the thread activating an internal Qt signal when the event is triggered. I presume there's a good reason why they do it that way.

iface_mon_enable() would be a no-op routine, as the Linux issue is specific to what I think is the "right" way to capture in monitor mode on Linux (create some kind of cloned adapter and put it into monitor mode).