We are a development environment. Our application sends UDP data packets to NICs on embedded third party hardware (i.e., can't run WS on that end). In wanting to validate the transmission of the data as close to the destination as possible I placed an inline tap device (Ethernet ComProbe from FTE) next to the device. On the source machine, I can run WS and see the UDP data being sent and received. From the tap, I do not see our UDP packets. I see other data. When I filter on "udp", I see other UDP packets that are wrapped in higher protocols (e.g., NBNS). I tried other configurations to rule our hardware. I tried three hubs from three different manufactures. If I ping the device, I see the ICMP messages. But, still I do not see the UDP data packets. Any thoughts on why the simple UDP packets are not displayed? Thanks, Ed. asked 12 Feb '16, 07:24  ejhellertc |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
MITM is usually understood in a very specific meaning which doesn't match what you do.
If I get you right, you can see the UDP responses of those embedded boards to your UDP requests so you are 100% sure that the boards do receive your UDP packets and you only need to find out why the tap does not show them to you? Or the boards send their UDP packets regardless whether they receive any from you? Because in this case, something between your PC and the hub could filter out your UDP packets so that they would really never reach the embedded device.
For some reason, when I checked back later to see if there was an answer, this did not show up. I guess it is a comment, not an answer. In any event. My setup is as follows: ServerA communicates with DeviceB using simple UDP data packets. From ServerA, I can run WireShark and see the packets out and the packets in. If I place a hub in between the server and device, I do not see the packets. I do see ICMP packets between the server and the device. At the same time, I still see the UDP packets when running WS on the server.
The way you put it it sounds really weird, but it is a known fact that some firewall, antivirus, or even VPN software may prevent Wireshark (actually, WinPcap) from seeing some packets (see related Questions at this site) and the logic determining which packets get through and which don't differs case by case. So I could imagine that e.g. too small UDP packets or UDP packets carrying a specific contents would be blocked.
So as you say that Wireshark running on the Server doesn't have problems to show those packets, can you connect the ComProbe to the Server and capture simultaneously on both its "real" network interface and the one representing the ComProbe, in order to exclude that the other machine, which you supposedly use to capture "on the wire", suffers from that kind of issue?
If not, can you use another machine without any kind of firewall, antivirus etc. software to capture on the hub? For some kinds of such software, it is enough to disable them, others must be uninstalled. Or use linux machine and tcpdump (if you don't want to install Wireshark on it) to save the capture to a file and then open the file somewhere else using Wireshark.
As you can see the icmp traffic, I suppose you do capture in promiscuous mode.