SharpPcap.LibPcap.LibPcapLiveDevice Unable to activate the adapter

[larswilliam]

The SharpPcap.LibPcap.LibPcapLiveDevice is throwing the "Unable to activate the adapter" following:

var activationResult = LibPcapSafeNativeMethods.pcap_activate(PcapHandle);

using Windows 10 and Npcap 0.995 attempting MonitorMode = Active following:

winPcap.Open(DeviceMode.Promiscuous, readTimeoutMilliseconds, MonitorMode.Active);

The monitor mode works fine when using the Adapter with Wireshark.

[chmorgan]

Hello.

Does it work without promiscuous mode?

Chris

On Tue, Jun 11, 2019 at 6:06 PM larswilliam notifications@github.com wrote:

The SharpPcap.LibPcap.LibPcapLiveDevice is throwing the "Unable to activate the adapter" following:

var activationResult = LibPcapSafeNativeMethods.pcap_activate(PcapHandle);

using Windows 10 and Npcap 0.995 attempting MonitorMode = Active following:

winPcap.Open(DeviceMode.Promiscuous, readTimeoutMilliseconds, MonitorMode.Active);

The monitor mode works fine when using the Adapter with Wireshark.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/chmorgan/sharppcap/issues/71?email_source=notifications&email_token=AAJH4AFOJT73I3PAED7KLDLP2AOV5A5CNFSM4HXDXQZ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GY5THBQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJH4AFIVF75QDLVZG2V2C3P2AOV5ANCNFSM4HXDXQZQ .

[Blackburn29]

I am having this same issue with nPcap on windows 10 and also on MacOS. Seems to happen when i set read_timeout to anything <= 0.

In regards to your question, promiscuous or normal mode does not make a difference.

[larswilliam]

I also got the same exception with DeviceMode.Normal

read_timeout =1000

[Blackburn29]

@larswilliam what type of adapter are you trying to listen to? I think I figured this one out to where the adapter has to be active in windows. You may need to see if other devices are listening on the adapter, or maybe give your computer a restart. As for my issue with MacOS, I was able to solve this by setting the timeout to 1ms as I need packets in as close to real-time for my application.

[larswilliam]

Hello.

Does it work without promiscuous mode?

Chris …

Hi Chris, and many thanks for your excellent and useful work.

No it does not work without promiscuous mode (DeviceMode.Normal).

I have tried using Windows 10.0.17763 and both Npcap 0.993 and 0.995.

I have tried the to install the Npcap both with and without WinPcap API-Compatible Mode.

I have tried using both Alfa AWUS036NEH and Netgear A6210 WiFi USB adapters witch both work as expected with Wireshark when it comes to Monitor Mode.

However, the exception is always thrown like this:

When stepping into the exception I find this:

[chmorgan]

Can you provide a list of adapters as reported by Sharppcap and the one reported by Wireshark?

It looks like you are trying to open a remote capture connection, I'm not sure what the constraints on doing so are. Is this the same adapter you are opening on Wireshark?

[larswilliam]

Sure

As you see the adapter list is quite crowded, but it works with Wireshark. For this example I have WinPcap API-Combability mode unchecked and use the brand new Npcap 0.996. As before if fails the same way as mentioned above while Wireshark works ok.

[larswilliam]

The reason for the multiple adapters is Hyper-V ;-I

[chmorgan]

@larswilliam it might be worth asking the Npcap guys what might be going on. Sharppcap is calling standard apis provided by npcap. The fact that things changed with newer npcap means the library might have changed some behavior or gotten more strict about usage. If its an issue due to an api change we can make changes pretty quickly to accommodate.

[larswilliam]

After just reading bmenees comment that he posted 14 days ago at "SharpPcap is not working with latest npcap" I got inspired and rolled back the Npcap to 0.991 and got surprised!

SharpPcap 4.6.1 in combination with Npcap 0.991 works as supposed with monitor mode :-)

[guyharris]

You should report this to the Npcap developers.

Note:

pcap_activate() returns a status value. It can be converted to a string with pcap_statustostr() and, for error codes PCAP_ERROR, PCAP_ERROR_NO_SUCH_DEVICE, and PCAP_ERROR_PERM_DENIED, pcap_geterr() can be called on the pcap_t to get an additional error string; the latter string might be useful for the developer of the code using the pcap library or wrappers such as SharpPcap, and probably will be useful for the developer of libpcap/Npcap or SharpPcap if the problem doesn't appear to the developer of the program to be a bug in their program.

Perhaps the error string provided to the exception handler when pcap_activate() fails should 1) include the result of pcap_statustostr() and 2) for the error codes in question, also include the result of pcap_geterr().

[chmorgan]

@guyharris I'd like to run this down but if the OP isn't responding I'm inclined to close this out now. How did you spot this btw? ;-)

[chmorgan]

@guyharris and how have you been? Not sure if you recall me from some time ago but we've exchanged emails etc from 2014 and earlier.

[juyanith]

For what it's worth I am getting the same error. We have an application that opens the device in promiscuous mode for network monitoring. Using wireshark 2.6.x (and winpcap) network capture works properly but if we upgrade to wireshark 3.0 (npcap) we get this same error. Wireshark itself is able to open the device and capture packets of course. There doesn't seem to be a workaround; I've tried both normal and promiscuous modes and various timeout settings, all with the same error.

[juyanith]

I have done some more experimenting and I have found that Example5.PcapFilter.cs shows the same error.

SharpPcap.PcapException HResult=0x80131500 Message=Unable to activate the adapter (rpcap://\Device\NPF_{...device id here...}). Return code: -1 Source=SharpPcap StackTrace: at SharpPcap.LibPcap.LibPcapLiveDevice.Open(DeviceMode mode, Int32 read_timeout, MonitorMode monitor_mode, UInt32 kernel_buffer_size) in C:\sharppcap\SharpPcap\LibPcap\LibPcapLiveDevice.cs:line 281 at SharpPcap.LibPcap.LibPcapLiveDevice.Open(DeviceMode mode, Int32 read_timeout, UInt32 kernel_buffer_size) in C:\sharppcap\SharpPcap\LibPcap\LibPcapLiveDevice.cs:line 199 at SharpPcap.LibPcap.LibPcapLiveDevice.Open(DeviceMode mode, Int32 read_timeout) in C:\sharppcap\SharpPcap\LibPcap\LibPcapLiveDevice.cs:line 181 at Example5.PcapFilter.Main(String[] args) in C:\sharppcap\Examples\Example5.PcapFilter\Example5.PcapFilter.cs:line 50

Interestingly enough, Example3.BasicCap.cs does not have the error but it has code that checks if the device is a WinPcapDevice and calls its Open method instead: if(device is WinPcapDevice) { var winPcap = device as WinPcapDevice; winPcap.Open(SharpPcap.WinPcap.OpenFlags.DataTransferUdp | SharpPcap.WinPcap.OpenFlags.NoCaptureLocal, readTimeoutMilliseconds); }

[juyanith]

Last update for now. I was able to get our code to work by specifically calling WinPcapDevice.Open instead of ICaptureDevice.Open and then updating the ParsePacket call as follows: Change var packet = PacketDotNet.Packet.ParsePacket(e.Packet.LinkLayerType, e.Packet.Data); To var packet = PacketDotNet.Packet.ParsePacket(LinkLayers.Ethernet, e.Packet.Data);

The WinPcapDevice always has a LinkLayerType of Null but I know we are looking for ethenet packets. This works for our local application since we are only interested in UDP packets anyway. Maybe this will help track down the larger issue of why simply calling device.Open(DeviceMode.Promiscuous, ReadTimeout); causes the error though.

[guyharris]

Using wireshark 2.6.x (and winpcap) network capture works properly but if we upgrade to wireshark 3.0 (npcap) we get this same error.

What happens if you upgrade to Wireshark 3.0.4, which includes the most recent Npcap release, 0.9983?

[juyanith]

Sorry, I wasn't clear. The testing I did today was after upgrading to 3.0.4 and 0.9983 from 2.6.11 and winpcap. I also tried using npcap 0.991 but that had different issues (it would not detect adapters). Right now our code is working on npcap 0.9983 with the changes that I outlined above but I don't really know why the simple call to ICaptureDevice.Open does not.

[guyharris]

The testing I did today was after upgrading to 3.0.4 and 0.9983 from 2.6.11 and winpcap.

Are you getting a LinkLayerType of Null or Ethernet for the device with 0.9983? I assume the device is an Ethernet adapter rather than an internal loopback device, as WinPcap didn't offer loopback devices equivalent to the UN*X loopback device, although Npcap does.

[juyanith]

I am getting e.Packet.LinkLayerType == LinkLayers.Null using npcap 0.9983 on a network adapter (local network).

[guyharris]

Presumably LinkLayers is coming from LinkLayers.cs; those are a subset of DLT_ values.

It looks as if the LibPcap defines the LinkType method, and that WinPcapDevice inherits that method. The LinkType appears to come from the result of a call to pcap_datalink(), so, for an Ethernet device, it should be returning DLT_EN10MB/LinkLayers.Ethernet, i.e. 1, not DLT_NULL/LinkLayers.Null, i.e. 0.

If you capture on that same adapter with Wireshark, and you open up the Statistics > Capture File Properties window, what does it report for "Interface" and for "Link type" under "Interfaces"?

[juyanith]

Here is the relevant section under Interfaces: Interface | Dropped packets | Capture filter | Link type | Packet size limit Ethernet | Unknown | none | Ethernet | 262144 bytes

[guyharris]

OK, so Wireshark recognizes it as an Ethernet adapter, so if e.Packet.LinkLayerType is returning LinkLayers.Null, something weird is happening.

[chmorgan]

Hi @juyanith. Is there a possibility to run sharppcap from a source build and print out to the console the pcap_datalink()?

Also, do you see the same behavior if you run your application as admin vs a normal user?

[juyanith]

Following your advice to check pcap_datalink() I modified WinPcapDevice to print out the value after pcap_open() was called. The result was 1, aka Ethernet.

I then started looking for why PcapDevice.dataLink was Null and determined that the two WinPcapDeviceOpen(OpenFlags, ...) methods do not set the Active flag to true. The no parameter WinPcapDevice.Open() will set it to true however because it calls the base LibPcapLiveDevice.Open() method. Adding Active = true ensures that dataLink is set properly.

I don't believe I can submit a pull request so I'll attach a diff as it's a pretty small change.

winpcap_active_not_set.zip

[juyanith]

I took the advice @guyharris made earlier in this thread and added some calls to pcap_statustostr() and pcap_geterr(). The call to pcap_activate() now gives a somewhat more informative error message:

'Generic error' Error opening adapter: The system cannot find the device specified. (20)

Unfortunately I'm not sure where to go from here. I'd rather not have to include the type-checking code but explicitly using WinPcapDevice works while LibPcapDevice does not.

Edit to add diff if it is useful: improve_error_detail.zip

[chmorgan]

Thank you for that testing and patch. It looks like you’ve found the issue. I can almost recall when the change was made but want to consult with the code. I’ll also look at how to use the status error functions to add more helpful strings to any errors or exceptions thrown.

Should be able to take a look at this today.

Chris

On Wed, Sep 18, 2019 at 11:35 AM juyanith notifications@github.com wrote:

I took the advice @guyharris https://github.com/guyharris made earlier in this thread and added some calls to pcap_statustostr() and pcap_geterr(). The call to pcap_activate() now gives a somewhat more informative error message:

'Generic error' Error opening adapter: The system cannot find the device specified. (20)

Unfortunately I'm not sure where to go from here. I'd rather not have to include the type-checking code but explicitly using WinPcapDevice works while LibPcapDevice does not.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/chmorgan/sharppcap/issues/71?email_source=notifications&email_token=AAJH4AFJYSEFSOEAWNGZTODQKJDFRA5CNFSM4HXDXQZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7APYMA#issuecomment-532741168, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJH4AEYRHCBWPXEGFLJVVTQKJDFRANCNFSM4HXDXQZQ .

[chmorgan]

@juyanith pushed the fix out to master, would you mind giving it a spin? It's the same as your changes, although I did make the edits manually.

[juyanith]

@chmorgan I pulled the changes and it fixes the LinkType issue in WinPcapDevice. Thanks! Any thoughts on what is up with the LibPcapLiveDevice issues?

The main thing I've noticed is that they use the library differently. WinPcapDevice calls SafeNativeMethods.pcap_open() and LibPcapLiveDevice calls LibPcapSafeNativeMethods.pcap_create() followed by LibPcapSafeNativeMethods.pcap_activate(). It's that last call that gets the error. It makes me wonder if it is some sort of security policy that is causing the issue.

[chmorgan]

@juyanith it could be related to a security policy. I'm not seeing any issues here in my usage, which does tend to be linux though rather than windows. Are you seeing that issue in your current setup that could provide a test case?

[guyharris]

The main thing I've noticed is that they use the library differently. WinPcapDevice calls SafeNativeMethods.pcap_open() and LibPcapLiveDevice calls LibPcapSafeNativeMethods.pcap_create() followed by LibPcapSafeNativeMethods.pcap_activate(). It's that last call that gets the error. It makes me wonder if it is some sort of security policy that is causing the issue.

At least in WinPcap 4.1.3, pcap_open() parses the string passed to it to see if it's a URL or not and, if it's not a URL or is a URL that refers to a local device, calls pcap_open_live() with the device string. pcap_open_live() calls pcap_create(), pcap_set_snaplen(), pcap_set_promisc(), and pcap_set_timeout(), sets an internal flag that only affects the behavior on macOS, and calls pcap_activate().

So it all ends up in pcap_create() and pcap_activate(), no matter whether you use those routines, pcap_open_live(), or pcap_open().

If you're passing a string of the form "rpcap://\Device\NPF_{...device id here...}", that is NOT supported by any pcap API other than pcap_open(), because only pcap_open() does the check for a URL and, if it's a URL that refers to a local device, as that one does, strip the URL scheme off and pass that to pcap_open_live().

The extra "rpcap://" doesn't serve a useful purpose; you could just pass "\Device\NPF_{...device id here...}" to all the pcap device-opening APIs and they'd work Just Fine.

[chmorgan]

@guyharris the "rpcap://" is appended by npcap but agreed that we don't need that prefix, see https://github.com/chmorgan/sharppcap/issues/78 :-)

[guyharris]

the "rpcap://" is appended by npcap

"Putting the "backward" in "backward compatibility"" - that's what pcap_findalldevs_ex() does in WinPcap, and thus what it does in the versions of libpcap that have it, and thus what Npcap does. It's not there to make any other pcap APIs happy, it's there just in case some program using it expects a URL scheme at the beginning of everything pcap_findalldevs_ex() supplies.

I will be so happy once I can replace both pcap_open() and pcap_findalldevs_ex() with new APIs that handle both local and remote capture.

Programs should probably using pcap_open() and pcap_findalldevs_ex() only when doing remote captures; that, for example, is what tcpdump does.

[juyanith]

And sure enough, if I add a hack to remove the "rpcap://" from the name the problem goes away.

[chmorgan]

Closing this out as there was a bug in an older npcap version, at least from what I read on the npcap issues list on GitHub, and there were a couple of bugs in Sharppcap around not activating the device. Also we've reduced the scope of pcap_findalldevs_ex() to only the necessary code path so device names should be cleaner for everyone now.

[Rookian]

Hi guys! I have the same problem.

I use npcap 0.9884 and SharpPcap 5.0.0.

When I use npcap 0.991 I dont get any device interfaces. With npcap 09884 I get all device interfaces but receive the error "Unable to activate the adapter" when opening the device.

Any idea? If you need some more information let me know.

Exception: SharpPcap.PcapException: 'Unable to activate the adapter (rpcap://\Device\NPF_{0386F299-E2D5-4456-B590-D128BB3A739E}). Return code: -5'

[chmorgan]

Hi Alex.

Can you try sharppcap from master? This has some fixes to winpcap device that may resolve the activation issue. If everything looks good I’ll look to schedule a new version release in the near future.

Regards, Chris

On Wed, Nov 13, 2019 at 3:58 PM Alex notifications@github.com wrote:

Hi guys! I have the same problem.

I use npcap 0.9884 and SharpPcap 5.0.0.

When I use npcap 0.991 I dont get any device interfaces. With npcap 09884 I get all device interfaces but receive the error "Unable to activate the adapter" when opening the device.

Any idea? If you need some more information let me know.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/chmorgan/sharppcap/issues/71?email_source=notifications&email_token=AAJH4AGAVAFETDHPPML7SJLQTRS6DA5CNFSM4HXDXQZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED7UCDQ#issuecomment-553599246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4AD6S4YDJPK53YI2VW3QTRS6DANCNFSM4HXDXQZQ .

[Rookian]

@chmorgan Yes, this is working!
You just changed the device name. I created myself a small helper to get the best interface (win32 API) for a given IP address.

Old Code

public static ICaptureDevice GetDefaultCaptureDevice(this IPAddress ip)
{
    var nicName = NIC.GetDefaultId(ip);
    var device = CaptureDeviceList.Instance
        .SingleOrDefault(x => x.Name.Replace("rpcap://\\Device\\NPF_", "") == nicName);
    return device;
}

New Code

public static ICaptureDevice GetDefaultCaptureDevice(this IPAddress ip)
{
    var nicName = NIC.GetDefaultId(ip);
    var device = CaptureDeviceList.Instance
        .SingleOrDefault(x => x.Name.Replace(@"\Device\NPF_", "") == nicName);
    return device;
}

So please ship the new version :bow: :rocket:

[SkyLeite]

Any updates on shipping the new version?

[chmorgan]

5.1.0 is pushed to nuget as of yesterday or the day before. This has a handful of fixes and the npcap namespace and updates packetdotnet and other dependent assemblies to their latest versions.

Chris

On Wed, Dec 11, 2019 at 4:37 PM Rodrigo Leite notifications@github.com wrote:

Any updates on shipping the new version?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chmorgan/sharppcap/issues/71?email_source=notifications&email_token=AAJH4AGHCAGGSIQM4TCWWRLQYFMQDA5CNFSM4HXDXQZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGUU6PI#issuecomment-564743997, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4AAFZ3ZSAOLO52TKDVDQYFMQDANCNFSM4HXDXQZQ .

[dqk0902]

[Exception] SharpPcap.PcapException: Unable to activate the adapter (ens6f0). (Error Code: PermissionDenied) Is anyone have the same error?

[kayoub5]

@dqk0902 create your own issue with detailed context