This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Unable to communicate on Non RealTek Network Adaptors

0

Hi,

I am facing a weird problem...my PC has a RealTek PCIe GBE Family Controller Network card. I am trying to send data over UDP to my target embedded board using my own custom made GUI. Whenever wireshark is open in my PC, I can communicate successfully. However, if Wireshark is off, I cant communicate.

Also, on other PCs having a non-Realtek adaptor, I cant communicate with the target board even if Wireshark is open. Wireshark doesnt show any packets being sent by the GUI to the board. I have tried reinstalling both, Wireshark and Winpcap drivers but the issue still persists. I also have the latest drivers for my network card installed on my PC. For sending data over UDP, the GUI is developed using MS Visual Studio 2008 using winsock library 2.0. I have used standard UDP protocol APIs for performing all the UDP operations.

Is the issue related to Wireshark or Network card or something else? Please assist.

asked 14 May '16, 06:58

mihirkarkhane's gravatar image

mihirkarkhane
6112
accept rate: 0%


One Answer:

0

As per your description it may be actually multiple issues combined.

While a Wireshark capture is running in promiscuous mode (or, in newer versions, also while the Wireshark's idle window shows the traffic graph on individual interfaces), the MAC address filter in the NIC's hardware is disabled. So if your embedded board sends data to proper IP address but to wrong MAC address, use of promiscuous mode hides that issue and the communication works. This scenario would be applicable if your embedded board is connected to the PC directly, using a cable, or there would be a hub (not switch!) between them.

The fact that Wireshark doesn't show any packets sent to the embedded board may mean that the PC cannot send them because it never gets an answer to its ARP requests from the embedded board (but the fact that it works with Realtek makes this reason questionable), or an issue with the capturing in general caused by some interfering software drivers installed on the capturing PC, as explained several times around here.

So I would recommend you to test capture on your "realtek" and "non-realtek" PCs while they would communicate over the same Ethernet interface with something else than your embedded board. This should tell you what to concentrate on first.

answered 14 May '16, 09:51

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%