On Sep 5, 2019, at 10:45 AM, Pascal Quantin <pascal@xxxxxxxxxxxxx> wrote:
>
> Le jeu. 5 sept. 2019 à 19:40, Jaap Keuter <jaap.keuter@xxxxxxxxx> a écrit :
>> So, are the new maintenance releases pending on yet another Npcap release?
>> Noticed that Npcap 0.9983 was just release today.
>
> I will update our bundled Npcap (as usual) but like last time I wait a bit to ensure that no blocking bug appears in their bug tracker right after the release.
See bug 14101
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14101
and bug 15575
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15575
both of which should be addressed by 0.9983. 0.9983 also apparently does loopback capture in a different fashion:
Loopback capture and injection no longer requires the Npcap Loopback Adapter to be installed. This is a minor API change, so Nmap 7.80 and earlier will still require the adapter to do localhost scans, but Wireshark and most other software will not require changes. Loopback capture uses the device name NPF_Loopback instead of NPF_{GUID}, where GUID has to be looked up in the Registry. The Npcap Loopback Adapter can still be installed by selecting "Legacy loopback support" in the installer or using the /loopback_support=yes command-line option. The LoopbackSupport Registry value will always be 0x00000001.
Somebody claims, in this Q&A question:
https://ask.wireshark.org/question/11356/loopback-npcap-added-in-win10-network/
that the loopback adapter is causing a problem, although I don't understand what the problem is ("The reason we have to disable it, it is showing APIPA 169.254.x.x and therefore affecting my Image program Storagecraft Image Manager which points to 127.0.0.1"? The Npcap Loopback Adapter isn't showing a normal loopback address, it's showing a non-loopback APIPA-assigned address, and that's somehow breaking normal network access to the local host using the loopback address?), so maybe that will fix that issue as well.
Once in the past I updated Npcap right after the release of a new version and we packaged a version that broke BPF filters. It was suggested by that time that we should wait a bit to confirm that no blocking issue (like a BSoD for example) pops, which seemed a conservative but still good approach. I was not saying that we should wait weeks, but one day or two.
Anyway as I intended to update it in the coming days I will do it now as there seems to be a strong push.
Pascal.
