Hello,
I've given a try to npcap-nmap-0.06-r7 downloaded from here as an installer (I am unable to compile from source) as a replacement (i.e. no coexistence mode) to WinPcap 4.1.3 which came along with Wireshark 2.0.2. My OS is a 64-bit Win10 (Czech language version and a result of upgrade from Win 7 if that may matter).
Issue number 2 is that when capturing on the loopback interface, npcap adds two extra octets somewhere at the beginning of the IPv4 header, causing already the IP addresses to be corrupt. In detail, a packet actually sent from 192.168.5.158 to 239.255.255.250 looks as if it was sent from 0.0.192.168 to 5.158.239.255 and its IPv4's payload was beginnig with 0xff 0xfa, as can be seen in the attached file.
The frame truncation problem as described in another Issue exists on the loopback interface too.
Do you need any additional information from me to help identify the issue?
npcap_loopback_issue.zip
Hello,
I've given a try to npcap-nmap-0.06-r7 downloaded from here as an installer (I am unable to compile from source) as a replacement (i.e. no coexistence mode) to WinPcap 4.1.3 which came along with Wireshark 2.0.2. My OS is a 64-bit Win10 (Czech language version and a result of upgrade from Win 7 if that may matter).
Issue number 2 is that when capturing on the loopback interface, npcap adds two extra octets somewhere at the beginning of the IPv4 header, causing already the IP addresses to be corrupt. In detail, a packet actually sent from 192.168.5.158 to 239.255.255.250 looks as if it was sent from 0.0.192.168 to 5.158.239.255 and its IPv4's payload was beginnig with 0xff 0xfa, as can be seen in the attached file.
The frame truncation problem as described in another Issue exists on the loopback interface too.
Do you need any additional information from me to help identify the issue?
npcap_loopback_issue.zip