Attached is a simple vi modified from Simple UDP - Sender.vi. The only change was made to the port numbers and address. The new vi is called Simple UDPmm-Sender.vi
Remote Port was: 61557 change to:5000
Local Port was 61556 change to: 5000
Address: was localhost change to:192.168.1.1 (in this case)
When sending 3 or 5 bytes (or characters) it (Simple UDPmm-Sender.vi) works fine just like the original (Simple UDP - Sender.vi) . But change the number of characters to 4 , then we get Malformed Packets as Wireshark reports (see snapshot). Use this with "Simple UDP - Receiver.vi" in the examples.
This occurs in LV2014 and LV2016. We are using Windows 10.
Can someone throw some light on this and maybe provide a solution?
Good morning Mike (WN2A73),
I am slightly confused about the issue that you are seeing. Are you still receiving the packets correctly in LabVIEW? Does the “Malformed Packets” error only get thrown when you use Port 5000, or does it occur on other ports as well?
Does it work correctly?
I think Wireshark simply does a deep packet inspection and notices that the payload is not in a valid format for the applications that typically use port 5000. You can ignore that. I would stay away from ports that are assigned to well known applications but unless you are actually also running those, there's no problem.
I am assuming that LabVIEW does NOT throw any errors and the data is received correctly for any size. Is this correct?
In particular, if both the source and destination ports are 5000, wireshark might assume that the packets correspond to UNISTIM traffic used by NORTEL phones. Obviously, your payload may not correspond to such traffic.
EDIT: Actually your trace seems to assumme tapa protocol for the payload, and the wireshark dissector sees it as invalid for tapa (eth:ip:udp:tapa).
You can keep using these ports (unless they are occupied by another service), you can switch to different ports (recommended), or you probably can configure wireshark to not try to analyse the payload of UDP port 5000>5000 traffic.