[Bug] No Message Received Pub/Sub on Windows 11 x64

[liushuya7]

Describe the bug

Trying the example on Windows 11 x64, one terminal is publishing the data:

Opening session...
Declaring Publisher on 'myhome/kitchen/temp'...
Putting Data ('myhome/kitchen/temp': '[   0] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   1] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   2] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   3] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   4] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   5] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   6] Hello World')...
Putting Data ('myhome/kitchen/temp': '[   7] Hello World')...

But the subscriber terminal receives nothing:

Opening session...
Declaring Subscriber on 'myhome/kitchen/temp'...
Enter 'q' to quit...

I tried the exact same thing on Ubuntu 20.04, and everything works fine.
So, I guess zenoh-python doesn't support Windows 11 x86 yet?

To reproduce

1. Go to the /example folder
2. Open one PowerShell: python z_pub.py -k myhome/kitchen/temp -v 'Hello World'
3. In another PowerShell: python z_sub.py -k 'myhome/kitchen/temp'

System info

• Platform: Windows 11 x64
• CUP: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
• Python Version: tested with 3.8, 3.9, 3.10 (none of them worked)
• Tried with 'pip install eclipse-zenoh' and building from source (neither worked)

[liushuya7]

Tested on WSL with Ubuntu 20.04: it works.
On Windows: tried running PowerShell as Administrator -> still not working.

[gabrik]

Hi @liushuya7, it could be related to Windows Firewall blocking UDP multicast communications, therefore the Publisher and the Subscriber cannot leverage on Scouting for automatic discovery.

To verify it is the case please run the examples with these parameters:

Publisher: python z_pub.py -k myhome/kitchen/temp -v 'Hello World' -l tcp/127.0.0.1:7447
Subscriber: python z_sub.py -k 'myhome/kitchen/temp -e tcp/127.0.0.1:7447

If you see the data going through then you need to configure Windows Firewall to allow UDP multicast communications.

[cguimaraes]

I have been playing with multicast on Windows 10 recently, and I indeed had some issues with the multicast. The root cause was the Windows firewall blocking multicast traffic, as @gabrik is mentioning. I believe you are having the same issue.

[liushuya7]

Thanks! Yes, I was finally able to see the data going through using the commands @gabrik you gave. It must be due to the Windows Firewall blocking UDP multicast then. However, I looked up how to configure Windows Firewall to allow UDP multicast, no success.. @cguimaraes were you able to configure the Windows Firewall to allow UDP multicast?
I've opened all the UDP ports but it doesn't seem to work.

[cguimaraes]

In my case, I just add the application to the Windows Firewall exceptions list, since I was in a close environment. However, note what Windows Support mentions regarding such solution:

An application on the Windows Firewall exceptions list is allowed to receive all incoming traffic. In many ways, this is the easiest method. However, it creates a vulnerability that may not be required. Therefore, this method is less secure than the other methods.

Important: We do not recommend this method.

It seems that the other option to allow the multicast to go through is the one you are using. What did you set on the other wizard windows?

[liushuya7]

The other window is just a list of allowed applications and policies.
I have checked that the UDP multicast is already allowed on my Windows:

[liushuya7]

@gabrik

To verify it is the case please run the examples with these parameters:

Publisher: python z_pub.py -k myhome/kitchen/temp -v 'Hello World' -l tcp/127.0.0.1:7447
Subscriber: python z_sub.py -k 'myhome/kitchen/temp -e tcp/127.0.0.1:7447

I realize as long as the Publisher's endpoint is listening on tcp/127.0.0.1:any_port
Subscriber doesn't need to specify which endpoint to connect. I just did python z_sub.py -k myhome/kitchen/temp and it receives data.

[gabrik]

That's interesting because when not passing any listening locator it should listen to tcp/localhost:7447 (@OlivierHecart please correct me if I'm wrong), but maybe on Windows something strange happens.
We'll check on a Windows machine where it is actually listening.

I imagine that when starting the command the first time you Allowed the python interpreter to do network on both public and private so that should not be the problem right?