Closed zapek closed 3 years ago
Hi David, I think that I tested (but I am not sure) udp-discovery-cpp on Windows long ago when I started this project and after that something might break. You mentioned that udp-discovery-cpp is used by RetroShare and as far as I know RetroShare has Windows support. Does it mean that udp-discovery-cpp breaks RetroShare experience for existing Windows users? I am asking to understand the priority of this bug.
Yes, Retroshare has Windows support (and Linux).
For Retroshare Linux I can see the UDP packet being sent on the LAN, but not for Retroshare Windows. udp-discovery-cpp is used here: https://github.com/RetroShare/RetroShare/blob/master/libretroshare/src/services/broadcastdiscoveryservice.cc
I did some research and maybe it has to do with the following: https://stackoverflow.com/questions/3229317/send-udp-broadcast-on-windows-7
Nowadays, most Windows setup have more than one interface (Hyper-V, WSL, Docker, ...).
Can you please share your testing configuration (BTW you can use discovery_tool to try to reproduce the issue).
I have the following configuration:
macOS host, Windows guest with Parallels.
I build discovery_example with cl /EHsc ws2_32.lib discovery_example.cpp udp_discovery_ip_port.cpp udp_discovery_protocol.cpp udp_discovery_peer.cpp
command on Windows.
I build discovery_example with g++ discovery_example.cpp udp_discovery_ip_port.cpp udp_discovery_peer.cpp udp_discovery_protocol.cpp -o discovery_example
on macOS.
When launching discovery_example on Windows I am asked to allow discovery_example to communicate on two networks by Windows Firewall (I allow it).
macOS version of discovery_tool "can see" Windows build, but Windows build can't.
When running two instances of discovery_example on Windows everything works fine.
I'am not trying to say that there is no issue. I would like to repro the same issue that you are facing.
And also I would like to understand the impact of this issue on your user base because it can take quite a while before I will be able to resolve it.
I'll try to get it to build. AFAIK they use msys2 to build Retroshare but I don't think it should change anything compared to Visual Studio. One thing is that on my setup when I type ipconfig in a shell, I get several interfaces (192.168.1.x for my LAN, 172.21.176.x for Docker on WSL and so on). I suspect this is part of the problem.
Hi David, can you please check the enum-interfaces
branch. This change introduces the function that enums network interfaces that allows peers to send UDP packets to broadcast address for each interface individually. The function is only implemented on Windows (on other platforms the behaviour is unchanged).
Again you can try to build discovery_example
with the cl /EHsc ws2_32.lib iphlpapi.lib discovery_example.cpp udp_discovery_ip_port.cpp udp_discovery_network_interfaces.cpp udp_discovery_peer.cpp udp_discovery_protocol.cpp
command on windows. Or you can try to use CMake as described in https://github.com/truvorskameikin/udp-discovery-cpp#how-to-run-the-example-program-and-a-discovery-tool.
I tried building using cygwin and it works and discovers the peers fine.
BUT... I also tried with the normal branch and... it works too.
Then I checked a running Retroshare and I could see the packets as well. All of the above on Windows.
Well, this is embarrassing. I'm certain it didn't work before, I checked with Wireshark then checked from a Linux box with tcpdump to make sure (it could see the packets from the Linux version fine). Which is why I concluded there was a problem with the Windows version. I also got a confirmation from someone else. And now he confirms it works on his setup today as well. Maybe a Windows Update changed something?
I'm sorry I made you do this version for nothing. I hope it didn't take you too much time :-/ In any case the current version works fine it seems!
No worries! And thanks for the confirmation that everything works!
Has udp-discovery-cpp been tested with Windows 10?
The following software uses udp-discovery-cpp: https://github.com/RetroShare/RetroShare
If I use netstat, I can see that the port is bound properly with the right process but if I check with Wireshark, there's no packet being sent. If I run the linux version then I can see the traffic properly.