Skip to content

Nmap 7.70 with Npcap 0.99-r2 in WinPcap API-compatible mode can't scan localhost #392

Closed

Description

@dmiller-nmap

Nmap 7.70 is failing to inject packets on the Npcap Loopback Adapter, but only when Npcap is installed in WinPcap API-compatible mode. Everything looks fine, but all ports come back filtered and Wireshark doesn't see the traffic. In native install mode, everything works. In both modes, packet injection on other interfaces (for remote scans) works fine.

Activity

  1. dmiller-nmap commented on Mar 29, 2018

    @dmiller-nmap
    ContributorAuthor

    Affects Npcap 0.99-r1 and 0.99-r2, but not earlier releases.

  2. dmiller-nmap commented on Apr 3, 2018

    @dmiller-nmap
    ContributorAuthor

    This is because we started using the Service registry key ("HKLM:\System\CurrentControlSet\Services\npcap\Parameters" usually, but also "npf\Parameters" under WinPcap API-compatible mode) to determine installation settings and features. Specifically, the LoopbackAdapter value needs to be read by the driver in order to do injection on the loopback adapter. NPFInstall.exe -il is writing it only to the "npf\Parameters" key, so the standard driver doesn't see it.

    Remaining questions that need to be answered before we can fix it:

    1. Why is NPFInstall.exe using the "npf" service name? That should only be possible with NPFInstall2.exe, the WinPcap API-compatible version.
    2. How can or should NPFInstall.exe record the loopback adapter name for both versions of the driver? One possibility would be only allowing Npcap features like loopback capture and injection when using the native (i.e. not WinPcap API-compatible) driver and API.
  3. dmiller-nmap commented on Apr 4, 2018

    @dmiller-nmap
    ContributorAuthor

    It seems I was mistaken about NPFInstall.exe vs. NPFInstall2.exe. In WinPcap API-compatible mode, the former uses the "npf" name and the latter uses the "npcap" name. I don't see that this is documented anywhere, so I might change it. This would fix the problem for anything using the npcap service, but would then introduce it for things using the "npf" service name. As I mentioned, though, this could be a satisfactory solution, limiting newer features to programs using the Npcap API, not the WinPcap API.

  4. dmiller-nmap commented on Apr 5, 2018

    @dmiller-nmap
    ContributorAuthor

    Most likely fix for the next release will be installing the native "npcap service" version of NPFInstall.exe as NPFInstall.exe, and making NPFInstall2.exe be the WinPcap API-compatible "npf service" version. This will effectively shift the bug from the native mode to the compatible mode, which should only be used to allow legacy programs to run until they are rewritten for the Npcap API.

  5. transferred this issue fromnmap/nmapon May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions