Wireshark mailing list archives

Re: Npcap 0.04 call for test


From: Yang Luo <hsluoyb () gmail com>
Date: Mon, 17 Aug 2015 14:33:00 +0800

Hi Guy,

On Mon, Aug 17, 2015 at 11:02 AM, Guy Harris <guy () alum mit edu> wrote:


On Aug 16, 2015, at 7:39 PM, Jim Young <jyoung () gsu edu> 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 () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org
?subject=unsubscribe



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

Current thread: