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.
Related
I currently have an effect here that drives me crazy.
I got a Windows 10 PC System in a local network at home ( A typical 192.168.178.X network with a Fritzbox as DNS and Gateway)
Everything runs fine. The Windows PC can connect to the internet, I can browse, play games in the internet etc.
Now I am currently playing around with a little device (ESP8266 and an OLED) which is connected via WLAN to the Fritzbox, while my Windows PC is via cable. The device shall receive UDP messages (no broadcast, just direct) and display them on its OLED.
I programmed the device and start it, then doing a test via my android mobile (also in the network via Wireless), using some UDP tester app from the store. Every UDP Packet is perfectly received and displayed on the device.
Now I want to test it from the Windows PC. I downloaded a free tool from the internet (Packet Sender). Entered the address and port and gave it some text to send.
The device does not receive anything at all. Strange #1.
Now I do some little coding in Java on the PC now. A simple "Hello World UDP Sender". Taken directly from some tutorial. (Activated IPV4 as Parameter)
The device does not receive anything. Strange #2.
On the Windows PC I have VirtualBox installed with an ubuntu as guest.
I start Netcat within it and start a UDP session. Every single Text I type in appears perfectly in the device. Strange #3.
Now I am confused and could need some help.
What do I miss? Is there any setting in Windows that prevents simple UDP Packets (No Broadcast) from being sent to any host in the same network?
I googled the net but did not find any clue.
EDIT:
The PC seems not to be the problem (maybe). I did a packet recording with the fritzbox and the UDP packets arrive there. They just do not seem to reach any wireless device in my home network.
I still did not figure out the exact problem, but I think it is related to either my Fritzbox and/or my computers "relation" to it. After I updated my Windows 10 with the anniversary update, my PC got a new IP assigned. Now everything works.
I am developing a TCP protocol fuzzing software under Windows 7. I wanna to send self constructed TCP packet using Raw Sockets. But it seems that Microsoft forbid this for some security reasons. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740548(v=vs.85).aspx)
I know WinPcap can also send custom packets. But I don't want to build a packet from the Ethernet level. The parameters for Ethernet and IPv4 are so complex and drive me crazy. I only cares about the TCP above parts. Are there any solutions to workaround this? All I can think out is to change my Win7 to Windows 2008 R2, but it's a big project to do. I hope there are better ways?
After Windows XP Service Pack 1, the ability to send raw sockets has been disabled, however you can still read them.
You can modify the source code example provided by Microsoft in the WDK to enable raw sends again. For more information, check the link.
PCAUSA - How To Access To NIC Drivers From A Win32 Application
Alternatively, you may use WinPcap to inject packets into the network.
WinPcap
I am trying to write an application for myself to learn things and to use in my own office. What I am trying to write is:
I have two nics. First one is connected to internet and the other one is connected to network
I have enabled ICS (Internet Connection Sharing) in my own PC
Other computers (Laptops, iPads etc.) are connecting to internet using my PC
So my c works like a hotspot
I am trying to see where they are connecting to and log their IP and MAC address. If I can do this, I will also add sign-in function at future.
Actually, my LSP supports TCP, UDP and RAW protocols. It works both on x86 and x64 Windows OS (Tested on Windows 7). However, when I connect to internet through this PC using my iPad, it doesn't seem working. WSPStartup never called.
If you have any idea, I will be more than happy.
Bests,
You need to use NDIS, a library like WinPCAP would do the work.
I have an Arduino application talking over USB to an application on Windows 8 using the MAVLINK protocol. The connection appears as COM3.
Is there a Windows application that can spy on this connection and display the traffic going in both directions? Raw bytes are fine, I don't need the protocol decoded.
You could log serial port activity using Portmon. (Edit: You need to first connect to the local computer via the Computer menu, and you must start capture on the port before a program opens it.)
You may not want to log USB traffic. Such a log would include a lot of extra information relating to the USB to serial adapter which is providing COM3. Portmon would only give you the bytes transferred over COM3, and the Mavlink protocol is entirely contained within that data stream. If you're sure you want to log all USB traffic to and from that device, then I recommend SnoopyPro. In Windows 7, you need to run it as administrator.
If you can use Windows XP in your environment, USB sniff should work for you. If you need something more powerful (and are willing to pay a fee for it) then USBLyzer might be a viable option.
The answer is SnoopyPro, and you can download it at:
SnoopyPro Sourceforge
This tool allows you to get USB information and also USB communication data. I used it in the past to know how a USB device worked in order to do its driver on Linux. I used this tool as a sniffer.
Basically, SnoopyPro allows you to intercept, display, record and analyze the USB protocol and all transferred data between any USB device connected to your PC and applications. It can be successfully used in application development, USB device driver or hardware development and offers the powerful platform for effective coding, testing and optimization.
I've been using winpcap to send raw packets over a wired connection for a while now. I'm building my own protocol (nothing special, just getting the hang of it) but now I want to extend it to wireless connections too. Does winpcap allow me to send raw packets over a wireless adapter?
I'm using VC++ on windows xp and windows 7. On my windows 7 machine it seems to work, but on my xp machine winpcap can't even open my adapter to send/receive packets. I tried to launch wireshark on my xp machine to see if the packets sent from my other machine arrived, but I wireshark couldn't open my wireless adapter either. Then rebooted into ubuntu and tried again. This time the wireshark did work, but the packets didn't show up.
Is there anything I should know about winpcap's limitations regarding wireless transmission? And if there are limitations is there an alternative that can let me send raw packets over wireless network on windows?
If "raw" means "raw 802.11 packets", then libpcap might allow it, but WinPcap, not so much. See my answer to another question. If you can put the adapter into monitor mode on Linux, *BSD, or OS X, you might be able to send raw 802.11 packets. On Windows, however, not only is putting it into monitor mode going to take a significant amount of work (probably including new kernel-mode code!), once you've put it into monitor mode, it might be impossible to send any packets.
If "raw" just means "raw IP packets", then raw IP sockets should work as well - or not well - as on Ethernet.