My network card receive no packet until I start Wireshark listening

[fabrice-fricheteau]

Hi,

I just mount my new PC (ryzen 3700x bn X570 CM, last drivers and Bios) and since I have installed Wireskark on it, there is no way to receive packets, until I start a capture.

If wireshark is not running I have no connexion.

It's like the network card refuse it

With or without the Windows Firewall

DiagReport-20200807-120801.txt

At the second I start a capture, connexion come back to live.

I try ncap 0.9994 and 0.9995, same behavior.

Unistalling wireshark and ncap doesn't retablish the network.

I have to stay on capture all the time...

[guyharris]

Meaning that packets that arrive on the network adapter don't get seen by the network stack unless Npcap is capturing packets?

[guyharris]

Does it matter whether Wireshark is capturing in promiscuous mode? Try it both with promiscuous mode turned on and with promiscuous mode not turned on.

[fabrice-fricheteau]

Dear Sir,

I tried and tried different way to activate and deactivate the promiscuous mode.

Form the capture page, from the setting...

Me too I was putting hope on this one.

But nothing changes.

for now I run Wireshark all bay with a file rotate...

kind regards

Le ven. 7 août 2020 à 20:10, Guy Harris [email protected] a écrit :

Does it matter whether Wireshark is capturing in promiscuous mode? Try it both with promiscuous mode turned on and with promiscuous mode not turned on.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670643490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMWD77KHKFWMZBZOFT3R7Q7RXANCNFSM4PXP47KQ .

[guyharris]

So:

• if Wireshark isn't capturing, networking isn't working;
• if Wireshark is capturing when not in promiscuous mode, networking works;
• if Wireshark is capturing in promiscuous mode, networking works?

What happens if you just have Wireshark running at its main screen, with the network traffic graphs running, rather than capturing?

[fabrice-fricheteau]

your's right.

Wireshark on the startup screen = no network

I ping my gateway to figure out.

as soon as I got the capture button, the ping goes live.

it works only if capture on the Ethernet card.

on a other virtual card in the list : no effect.

I don't have much than windows freshly install on it.

no wireless card.

kind regards

Le sam. 8 août 2020 à 02:39, Guy Harris [email protected] a écrit :

So:

• if Wireshark isn't capturing, you don't appear to be getting network traffic from the adapter
• if Wireshark is capturing when not in promiscuous mode, networking works;
• if Wireshark is capturing in promiscuous mode, networking works?

What happens if you just have Wireshark running at its main screen, with the network traffic graphs running, rather than capturing?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670797091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMWMF45LNOTEID4AHUTR7SNEBANCNFSM4PXP47KQ .

[guyharris]

your's right. Wireshark on the startup screen = no network

Was there a line on the startup screen corresponding to your Ethernet adapter? Does it show any traffic when you ping the gateway?

[fabrice-fricheteau]

I'm able to capture on the firewall just in front.

What I can see there is that all packets that come from the computer is replied. Those packet are surely received but not correctly interpret.

On Wireshark there is the Ethernet card classic that I use to capture.

there is the loopback installed by Wireshark plus to other that should be some virtual additional.

tell me if you want some traces, diags or logs.

kind regards

Le sam. 8 août 2020 à 02:59, Guy Harris [email protected] a écrit :

your's right. Wireshark on the startup screen = no network

Was there a line on the startup screen corresponding to your Ethernet adapter? Does it show any traffic when you ping the gateway?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670799900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMRF2LH3VZVF4XCJZHDR7SPONANCNFSM4PXP47KQ .

[guyharris]

I'm able to capture on the firewall just in front. What I can see there is that all packets that come from the computer is replied. Those packet are surely received but not correctly interpret.

So there's an interface on your machine, shown by Wireshark, that corresponds to the Windows firewall?

On Wireshark there is the Ethernet card classic that I use to capture.

So that's the card on which networking only works you're running Wireshark?

Wireshark should display a line on the startup screen for each of the interfaces, including the Ethernet adapter. Is it showing a line for that adapter? If so, does that line show any traffic, or is it just a flat line? If it's just a flat line, what happens if you try pinging the gateway - does that cause the line to show some traffic?

Was there a line on the startup screen corresponding to your Ethernet adapter?

there is the loopback installed by Wireshark

Installed by Npcap.

[fabrice-fricheteau]

Please find the after launching the capture on the Ethernet card

https://photos.app.goo.gl/2fno4gZtH48upwwx6

My Firewall is a Sonicwall TZ210, My switch is a Cisco 2960 with a basic setting on it.

Le sam. 8 août 2020 à 10:42, Guy Harris [email protected] a écrit :

I'm able to capture on the firewall just in front. What I can see there is that all packets that come from the computer is replied. Those packet are surely received but not correctly interpret.

So there's an interface on your machine, shown by Wireshark, that corresponds to the Windows firewall?

On Wireshark there is the Ethernet card classic that I use to capture.

So that's the card on which networking only works you're running Wireshark?

Wireshark should display a line on the startup screen for each of the interfaces, including the Ethernet adapter. Is it showing a line for that adapter? If so, does that line show any traffic, or is it just a flat line? If it's just a flat line, what happens if you try pinging the gateway - does that cause the line to show some traffic?

Was there a line on the startup screen corresponding to your Ethernet adapter?

there is the loopback installed by Wireshark

Installed by Npcap.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670845906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMT5KDR7TFQW3NP42NTR7UFV5ANCNFSM4PXP47KQ .

[guyharris]

Please find the after launching the capture on the Ethernet card

In the second photo, at the startup screen, Wireshark is showing traffic on the Ethernet adapter, but the pings timed out. In that case, Wireshark is capturing traffic, but not in promiscuous mode - that's how it sees the packets to count them and display them in the graphs (it doesn't do it by getting interface statistics, it does them by capturing packets and counting them).

In the first photo, Wireshark is displaying packets, and it appears that the capture is in progress and hasn't been stopped (the red "stop" button isn't grayed out, and the blue "start" button is). There's no indication whether the capture is being done in promiscuous mode, but the terminal window shows pings timing out and then succeeding.

So my guess is that, somehow, the pings are working only when a capture is being done in promiscuous mode. (The capture to show the graphs is also being done with a short snapshot length - all Wireshark cares about is the number of packets, not the contents of the packets, and a short snapshot length reduces the chances that packets will be dropped, as less space is consumed in the kernel buffers used on most operating systems, including Windows with WinPcap/Npcap - and perhaps that makes the difference.)

The fact that the graph on the startup screen is showing traffic for the Ethernet means that the driver for the Ethernet adapter is passing packets to NDIS (otherwise, Npcap wouldn't be seeing the packets and passing them to Wireshark so that it can count them), but somehow either the pings aren't getting transmitted (so the gateway isn't seeing them and doesn't know that it should reply) or the replies aren't getting to the ping command.

Daniel, any ideas what might be happening? Any clues in the diagnostic report?

Another odd thing is that Wireshark is seeing both a "Npcap Loopback Adapter" and an "Adapter for loopback traffic capture". ipconfig/all shows the "Npcap Loopback Adapter", but doesn't show the "Adapter for loopback traffic capture". On my Windows 10 machine, with Npcap installed, I have only the "Adapter for loopback traffic capture"; I think the "Npcap Loopback Adapter" is left over from an earlier Npcap installation - I seem to remember that there was an issue where it didn't get removed when Npcap was updated. Daniel, am I remembering correctly? And would removing that interface make a difference here?

[fabrice-fricheteau]

Dear Sir,

This morning I have been delivered from my curse.

My computer has restarted in the night.

Once again, No network after startup.

So I start as usual wireshark listening on the ethernet adapter.

I was able to capture a bunch of ARP packets. But I couldn't see any packet related to my Fix IP.

I went checking my IPv4 settings set in manual. SURPRISE a blank instead of the IP and gateway.

It disappeared during the night.

I so try my luck in DHCP and second surprise, it worked... never did since days...

I so try to stop the capture and it now works without...

I can't even reproduce the issue.

And can't understand what happened...

Thank to you and your time trying to understand this mess.

See you next time if it come back...

Le sam. 8 août 2020 à 20:54, Guy Harris [email protected] a écrit :

Please find the after launching the capture on the Ethernet card

In the second photo, at the startup screen, Wireshark is showing traffic on the Ethernet adapter, but the pings timed out. In that case, Wireshark is capturing traffic, but not in promiscuous mode - that's how it sees the packets to count them and display them in the graphs (it doesn't do it by getting interface statistics, it does them by capturing packets and counting them).

In the first photo, Wireshark is displaying packets, and it appears that the capture is in progress and hasn't been stopped (the red "stop" button isn't grayed out, and the blue "start" button is). There's no indication whether the capture is being done in promiscuous mode, but the terminal window shows pings timing out and then succeeding.

So my guess is that, somehow, the pings are working only when a capture is being done in promiscuous mode. (The capture to show the graphs is also being done with a short snapshot length - all Wireshark cares about is the number of packets, not the contents of the packets, and a short snapshot length reduces the chances that packets will be dropped, as less space is consumed in the kernel buffers used on most operating systems, including Windows with WinPcap/Npcap - and perhaps that makes the difference.)

The fact that the graph on the startup screen is showing traffic for the Ethernet means that the driver for the Ethernet adapter is passing packets to NDIS (otherwise, Npcap wouldn't be seeing the packets and passing them to Wireshark so that it can count them), but somehow either the pings aren't getting transmitted (so the gateway isn't seeing them and doesn't know that it should reply) or the replies aren't getting to the ping command.

Daniel, any ideas what might be happening? Any clues in the diagnostic report?

Another odd thing is that Wireshark is seeing both a "Npcap Loopback Adapter" and an "Adapter for loopback traffic capture". ipconfig/all shows the "Npcap Loopback Adapter", but doesn't show the "Adapter for loopback traffic capture". On my Windows 10 machine, with Npcap installed, I have only the "Adapter for loopback traffic capture"; I think the "Npcap Loopback Adapter" is left over from an earlier Npcap installation - I seem to remember that there was an issue where it didn't get removed when Npcap was updated. Daniel, am I remembering correctly? And would removing that interface make a difference here?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670961850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMWTGSFSOVGZTFY6KTTR7WNPRANCNFSM4PXP47KQ .

[fabrice-fricheteau]

Didn't take long.

I'm back in the issue

Wireshark still need to be capturing to get network.

Le mer. 12 août 2020 à 09:20, fabrice fricheteau < [email protected]> a écrit :

Dear Sir,

This morning I have been delivered from my curse.

My computer has restarted in the night.

Once again, No network after startup.

So I start as usual wireshark listening on the ethernet adapter.

I was able to capture a bunch of ARP packets. But I couldn't see any packet related to my Fix IP.

I went checking my IPv4 settings set in manual. SURPRISE a blank instead of the IP and gateway.

It disappeared during the night.

I so try my luck in DHCP and second surprise, it worked... never did since days...

I so try to stop the capture and it now works without...

I can't even reproduce the issue.

And can't understand what happened...

Thank to you and your time trying to understand this mess.

See you next time if it come back...

Le sam. 8 août 2020 à 20:54, Guy Harris [email protected] a écrit :

Please find the after launching the capture on the Ethernet card

In the second photo, at the startup screen, Wireshark is showing traffic on the Ethernet adapter, but the pings timed out. In that case, Wireshark is capturing traffic, but not in promiscuous mode - that's how it sees the packets to count them and display them in the graphs (it doesn't do it by getting interface statistics, it does them by capturing packets and counting them).

In the first photo, Wireshark is displaying packets, and it appears that the capture is in progress and hasn't been stopped (the red "stop" button isn't grayed out, and the blue "start" button is). There's no indication whether the capture is being done in promiscuous mode, but the terminal window shows pings timing out and then succeeding.

So my guess is that, somehow, the pings are working only when a capture is being done in promiscuous mode. (The capture to show the graphs is also being done with a short snapshot length - all Wireshark cares about is the number of packets, not the contents of the packets, and a short snapshot length reduces the chances that packets will be dropped, as less space is consumed in the kernel buffers used on most operating systems, including Windows with WinPcap/Npcap - and perhaps that makes the difference.)

The fact that the graph on the startup screen is showing traffic for the Ethernet means that the driver for the Ethernet adapter is passing packets to NDIS (otherwise, Npcap wouldn't be seeing the packets and passing them to Wireshark so that it can count them), but somehow either the pings aren't getting transmitted (so the gateway isn't seeing them and doesn't know that it should reply) or the replies aren't getting to the ping command.

Daniel, any ideas what might be happening? Any clues in the diagnostic report?

Another odd thing is that Wireshark is seeing both a "Npcap Loopback Adapter" and an "Adapter for loopback traffic capture". ipconfig/all shows the "Npcap Loopback Adapter", but doesn't show the "Adapter for loopback traffic capture". On my Windows 10 machine, with Npcap installed, I have only the "Adapter for loopback traffic capture"; I think the "Npcap Loopback Adapter" is left over from an earlier Npcap installation - I seem to remember that there was an issue where it didn't get removed when Npcap was updated. Daniel, am I remembering correctly? And would removing that interface make a difference here?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670961850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMWTGSFSOVGZTFY6KTTR7WNPRANCNFSM4PXP47KQ .

[billdotjr]

Same story here. I had very very old (v1) Wireshark installed, since my PC was continuously upgraded from Windows 7, to 8, to 10. I reinstalled Wireshark on Monday and ever since that my DHCP did not work. It took me 20 minutes every morning, shutting the port down on the switch combined with restarts and eventually it would start working. Today I tried static IP and it did not work either.

I identified the problem as unidirectional connectivity. My switch would show both input and output frames on the port, but windows would only show sent frames, but 0 received.

3.2.6 (v3.2.6-0-g4f9257fb8ccc)

Compiled (64-bit) with Qt 5.12.8, with WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4,
with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4, with
Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic
updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
resampler), with SBC, with SpanDSP, with bcg729.

Running on 64-bit Windows 10 (1903), build 18362, with Intel(R) Core(TM) i3-4130
CPU @ 3.40GHz (with SSE4.2), with 8144 MB of physical memory, with locale
Czech_Czechia.1250, with light display mode, without HiDPI, with Npcap version
0.9994, based on libpcap version 1.9.1, with GnuTLS 3.6.3, with Gcrypt 1.8.3,
with brotli 1.0.2, without AirPcap, binary plugins supported (19 loaded).

Built using Microsoft Visual Studio 2019 (VC++ 14.27, build 29111).

[guyharris]

3.2.6 (v3.2.6-0-g4f9257fb8ccc)

...

The key part of which is

with Npcap version 0.9994

[fabrice-fricheteau]

yes I think that's the issue.

because the Cisco switch see the packet going both way from and to the client.

As a brand new computer, I can also reset it.

it took me 2 min to install windows...

But if I do that, nobody will understand what happened..

as a network engineer, I'm ok to suffer until I know what's going on...

But we have to admit that we have few way to diagnose this issue...

is there a way to have more logs or more way to see what's going on ?

kind regards

Le ven. 7 août 2020 à 20:10, Guy Harris [email protected] a écrit :

Meaning that packets that arrive on the network adapter don't get seen by the network stack unless Npcap is capturing packets?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-670643269, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMUBTCYZEVM3RR4LNLDR7Q7PZANCNFSM4PXP47KQ .

[smowton]

+1: Wireshark auto-upgrading (from at least a year ago) and installing npcap-0.9994 resulted in no connectivity on boot, which is resolved by starting a Wireshark capture. Once the capture is started there's no need to keep it running. I haven't tried uninstalling/reinstalling npcap yet; will provide more details as I learn them.

ipconfig /all shows only one adapter: Ethernet adapter Ethernet 2. The adapter has all the usual clients, protocols, etc installed, plus "Npcap Packet Driver (NPCAP)".

Please let me know any debug info that would help you.

[fabrice-fricheteau]

Hi,

Back from holidays, the issue is still here.

One every 20 restart, it could work without starting the capture.

All 19 other time, I'm still have to run a capture. I notice that some time is displayed only the ncap interface and the base Ethernet interface.

I'm ready the investigate but I need action to do from your side. As a network engineer I able to troubleshoot deeply the issue If I know where to search..

kind regards

Le mer. 2 sept. 2020 à 20:37, Chris Smowton [email protected] a écrit :

+1: Wireshark auto-upgrading (from at least a year ago) and installing npcap-0.9994 resulted in no connectivity on boot, which is resolved by starting a Wireshark capture. Once the capture is started there's no need to keep it running. I haven't tried uninstalling/reinstalling npcap yet; will provide more details as I learn them.

ipconfig /all shows only one adapter: Ethernet adapter Ethernet 2. The adapter has all the usual clients, protocols, etc installed, plus "Npcap Packet Driver (NPCAP)".

Please let me know any debug info that would help you.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmap/npcap/issues/221#issuecomment-685923572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRCQMWM4DYHBOYREKONZODSD2GGZANCNFSM4PXP47KQ .

[mfmayer]

Something similar I'm also seeing here. But it's even more strange.

There are 3 machines in that subnet (with vlan id): 2x Windows, 1x Linux. From both Windows machines I can ping the Linux machine and I can also ping both Windows machines from Linux. But I can't ping one Windows machine from the other Windows machine (not even if firewall has been disabled).

Because this drove me crazy I've installed Wireshark on one of the Windows machines (with npcap). After installation and after starting capturing in promiscuous mode I was suddenly able to ping it also from the other windows machine. Without capturing in promiscuous mode (or even capturing without promiscuous mode) I can't ping it from the other windows machine. But I still can ping it from Linux.

Any ideas how this could be explained?

[guyharris]

After installation and after starting capturing in promiscuous mode I was suddenly able to ping it also from the other windows machine. Without capturing in promiscuous mode (or even capturing without promiscuous mode) I can't ping it from the other windows machine. But I still can ping it from Linux.

So, in your case:

• before Wireshark was installed, you could ping the Windows machine from the Linux machine but not from the other Windows machine;

• with Wireshark not running at all, you can ping the Windows machine from the Linux machine but not from the other Windows machine;

• with Wireshark running and capturing in non-promiscuous mode, you can ping the Windows machine from the Linux machine but not from the other Windows machine;

• with Wireshark running and capturing in promiscuous mode, you can ping the Windows machine either from the Linux machine or from the other Windows machine?

[mfmayer]

After installation and after starting capturing in promiscuous mode I was suddenly able to ping it also from the other windows machine. Without capturing in promiscuous mode (or even capturing without promiscuous mode) I can't ping it from the other windows machine. But I still can ping it from Linux.

So, in your case:

• before Wireshark was installed, you could ping the Windows machine from the Linux machine but not from the other Windows machine;
• with Wireshark not running at all, you can ping the Windows machine from the Linux machine but not from the other Windows machine;
• with Wireshark running and capturing in non-promiscuous mode, you can ping the Windows machine from the Linux machine but not from the other Windows machine;
• with Wireshark running and capturing in promiscuous mode, you can ping the Windows machine either from the Linux machine or from the other Windows machine?

exactly

[guyharris]

exactly

So that one sounds as if it's

• when the adapter on Windows machine A is not in promiscuous mode, you can ping that machine from the Linux machine but not from Windows machine B;

• when the adapter on Windows machine A is in promiscuous mode, you can ping that machine from the Linux machine and from Windows machine B.

If so, it may be that, for whatever reason, Windows machine B's ARP table has the a mapping from machine A's IP address to some MAC address other than that for Windows machine A. The arp command can, when run on machine A, be used to examine machine A's ARP table and, if necessary, remove bogus entries from it.

[mfmayer]

Actually I also suspected that it's related to wrong ARP entries. But I've checked it and even statically added it. It didn't make a difference.

[Martin-Maat]

You MAY be fooling yourself.

I had the same issue with somewhat larger packets (Wireshark "fixed" it). Smaller packets would pass just fine.

It could be you not allocating large enough receive buffers or send buffers on the receiving/sending sockets (see socket options).

It could be you not recognizing and separating your incoming dataframes properly. While you are the only one sending dataframes, these would come in sequentially and you would recombine them to packets. On a busier LAN segment datagrams from different packets may interleave the ones you are expecting and ruin the resulting packet.

It could be you not adopting incoming datagrams quick enough. If you do you ReceiveFrom and your processing on the same thread it may take too long for you to get back for the next datagram. If they arrive in quick succession, some may be lost. A larger receive buffer should help to mitigate this but having a dedicated thread to adopt incoming datagrams, just stuffing them into your own queue would be good..

Wireshark just slows things down and does the necessary buffering for you. This may camouflage your problem.

I must say I did all these things and larger packets still don't get through in my test environment while everything does work on my local machine. I have no issue if I stick to 508 bytes maximum datagram sizes. So there may still be some "smart" switch dropping datagrams or other issue I am not aware of yet.