Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.04 call for test

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Mon, Aug 17, 2015 at 11:02 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Aug 16, 2015, at 7:39 PM, Jim Young <jyoung@xxxxxxx> wrote:

> But unlike the earlier versions, the NPcap Loopback Adapter does no longer shows up in the list of interfaces available to Wireshark.

I suspect the most likely reason for this would either be that

        1) PacketGetAdapterNames() doesn't list the loopback adapter

PacketGetAdapterNames() calls IPHelper API to list adapters, if the loopback adapter is listed in ncpa.cpl, it should be enumerated by this API.

 

or

        2) it *does* list it, but pcap_findalldevs()'s subsequent attempt to open the device (to make sure it's openable) fails.

(The "openable" test is in the internal add_or_find_if() routine, and the reason, to quote the comment in the code, is:

                 * Can we open this interface for live capture?
                 *
                 * We do this check so that interfaces that are
                 * supplied by the interface enumeration mechanism
                 * we're using but that don't support packet capture
                 * aren't included in the list.  Loopback interfaces
                 * on Solaris are an example of this; we don't just
                 * omit loopback interfaces on all platforms because
                 * you *can* capture on loopback interfaces on some
                 * OSes.

I think this is the cause, because I added WSK init code into the OpenAdapter routine of the loopback adapter instead of the driver init routine for some reason, if the WSK init code fails, the loopback adapter will fail to be opened. And the debug trace from Pascal has confirmed this. To be specific, WSK_PROVIDER_DISPATCH::WskSocket method call fails, but I didn't know the error code. In Npcap 0.04 r2, I have added the error code in trace.

 

That was done when, as I remember, somebody complained that the loopback interface wasn't showing up in Linux or *BSD or OS X or one of the other OSes on which you *can* capture on the loopback interface, so, instead of leaving that interface out of the list, I added that check.

The check probably isn't necessary on Linux, as I *think* everything that shows up as a network interface from the various mechanisms Linux provides are OK to bind a PF_PACKET socket to, so nothing that simply doesn't support capturing should show up.

It *might* be useful on systems using BPF, as, alas, an interface can exist without the BPF mechanism being told about it; it'd be nice if there were a way to get BPF to enumerate the interfaces it knows about.

On Windows, the list of devices ultimately comes from the driver, so if we can't assume it doesn't supply devices that can't be opened, that's a bug in WinPcap/Npcap.

It is actually an issue of Npcap.

 

So maybe the "openable" test can be removed on at least some platforms.  That way, instead of the interface not showing up at all, it'll show up, but attempts to capture on it will get "permission denied" if you don't have permission to capture on it, making it clearer what the problem is.)

I don't know what solution fits other OSs best, but in Windows, the "openable" test is good, as it saves the effort to open an unopenable interface.

 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

Cheers,

Yang