Guy Harris

> t present, it supports the above 10 kinds No, it doesn't. There is no support for: - `DLT_EN3MB` - which is fine, as I don't think any adapters exist...

(Note that not all `DLT_` values in pcap/dlt.h are supported for live capture with libpcap. Many of them are assigned for use by other hardware or software that captures traffic...

A quick check of the source code for the NT driver for WireGuard indicates that it uses `NdisMediumIP` as the link-layer type; that value *already* gets mapped to `DLT_RAW`, so...

> c) Even on healthy hosts (not subject to this issue), every now and then it happens that the handle event is signalled (`WaitForMultipleObjects()` returns `WAIT_OBJECT_0`) but the subsequent `pcap_dispatch()`...

> 1] ... However, I've seen frames as large as 66546 bytes (`pcap_pkthdr::caplen == pcap_pkthdr::len`) successfully captured. Not sure why that happens either, as we explicitly call `pcap_set_snaplen(65535)` -- so...

> 3] No, the pcap handle is used from only one thread in the process (although it's not the main thread). So in that thread, are you in a loop...

> libpcap silently increases user buffer size to accommodate maximum storage for the current snaplen. Pro: works with any version of npcap driver. Con: minor (6126 bytes) increase in application...

Does `PacketOpenAdapter()` need to get a list of devices? If not, removing that requirement would help here. If so, fixing #175 so that fetching the device list doesn't require Administrator...

If pcapy were to implement `pcap_set_rfmon()`, it'd also have to implement `pcap_create()` and `pcap_activate()`, as, to open in monitor mode, you have to call `pcap_create()` to create the `pcap_t`, `pcap_set_rfmon()`...

> Which is strange because pcapy should be able to use the en0 interface when it's already been put into monitor mode through some other means Just because an *interface*...