Wireshark receives UDP multicast packages, but subscribing client application does not?

0
votes

Description

I am currently trying to publish timestamps on the raspberry pi and subscribe to them on my windows based PC. For this, I connected BOTH the Raspberry Pi and the Windows PC to a Switch. So, if I start the publish sample on the Raspberry Pi, I can already see the incoming UDP multicast packages in Wireshark on my Windows PC. So theoretically, the subscribe application also should be able to receive the packages and print them out to the console. But that is not the case. The subscribe sample does NOT print out any timestamps to the console which means, it does not receive any UDP multicast packages. Why is that? If I run both the publish and subscribe sample on the windows PC, it works...

I may have one clue what the problem could be: If I run both publish/subscribe samples on my windows pc, they both print out in the console, that they are listening opc.tcp://mypc:4801/ But when I run the publish sample on the raspi it says, it is listening on opc.tcp://raspberrypi:4840/ but the subscribe sample is still listening on opc.tcp://mypc:4801/ .

Any suggestions? Could the firewall be the problem here? Any advice is highly appreciated!!

Additional Informations

In the following image, you can see the IP address of the raspberry pi: enter image description here

Below you can see the transmitted UDP multicast packages in Wireshark. They do indeed came from the raspberry pi because the IP addresses match: enter image description here

1
raspberry-piudpwiresharkmulticastopen62541

1 Answers

0
votes

There could be a bunch of things that's making your datagrams not reach the application:

Ethernet frame less than 64 bytes

Most NICs will pad the data at the data link layer going out so this might not be an issue. Wireshark will not be able to see this having happened. To verify, try padding the data payload yourself with (say 0xFF) until the packet has more data than 64 bytes. This is fortunately less of a problem these days, but I have had this happen to me a long time ago.

Incorrect UDP checksum

If the calculated checksum doesn't match the checksum provided by the sender then the packet will be silently discarded. Wireshark by default doesn't compute the checksum and it hooks itself up before the driver get hold of the packet, especially if you run Wireshark in promiscuous mode. You can turn checksum validation on through Edit > Preferences > Protocols > UDP > Validate UDP checksum if possible.

If you can change the code on the sender side, set the UDP checksum header field to all zeroes to disable checksums.

Network adapter settings on Windows

If your machine is managed within an enterprise, then I know of at least a couple of adapter plugins that will interfere with unusual network packets. Try opening up the Properties dialog on your network adapter and have a peek.

Windows firewall

I am no expert on this, but I think the default setting of Windows firewall lets multicast through. Then again, if your computer is being managed centrally, policies might have been tweaked.