Hi All!
I am trying to run DDS 6.0.1 on 2 win 10 hosts and make them communicate, both windows firewalls are disabled, on localhost everything goes smoothly. I tried running rtiddsping on both machines (one as subscriber, other as publisher), but it seems they don't see each other.
I also tried rtiddsspy and it seems that each computer can see the topics that are started on the other machine:
RTI Connext DDS Spy built with DDS version: 6.0.1 (Core: 1.9a.00, C: 1.9a.00, C++: 1.9a.00)
Copyright 2012 Real-Time Innovations, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
rtiddsspy is listening for data, press CTRL+C to stop it.
source_timestamp Info Src HostId topic type
----------------- ---- ---------- ------------------ ------------------
1583102323.051999 W +N C0A8014E ph_topic ph2
1583102360.860988 d +N C0A8014E ph_topic ph2
1583102361.060999 d +M C0A8014E ph_topic ph2
Also, I checked pinging 224.0.0.1, it goes well on one of the computers, but on the other one it answers as:
Pinging 224.0.0.1 with 32 bytes of data:
PING: transmit failed. General failure.
I tried igmpquery and it resulted as follows, so it sees it also found the other end on the network.
IGMP query generator V1.4
Project web site: http://code.google.com/p/igmpquery/
Requires WinPcap
\Device\NPF_{CD7EFA8C-7C44-4F7B-94C3-782595122BC3}
Description: Microsoft
Address Family Name: AF_INET
Address: 192.168.1.69
Netmask: 255.255.255.0
Broadcast Address: 255.255.255.255
IGMPv2 general query 192.168.1.69 -> 224.0.0.1
listening for responses ...
\Device\NPF_{042CDDB6-9314-4F1C-A5E0-41129C3C1671}
Description: USB3.0 to Gigabit Ethernet Adapt
Address Family Name: AF_INET
Address: 192.168.1.64
Netmask: 255.255.255.0
Broadcast Address: 255.255.255.255
IGMPv2 general query 192.168.1.64 -> 224.0.0.1
listening for responses ...
\Device\NPF_{51EF9EFA-EEAB-4399-B635-D2C2F0CAE32D}
Description: Intel(R) Ethernet Connection (5) I219-LM
Address Family Name: AF_INET
Address: 192.168.1.72
Netmask: 255.255.255.0
Broadcast Address: 255.255.255.255
IGMPv2 general query 192.168.1.72 -> 224.0.0.1
listening for responses ...
23:20:14.207 192.168.1.78 -> 224.0.0.251 IGMP Rpt 224.0.0.251
23:20:14.207 192.168.1.78 -> 224.0.0.252 IGMP Rpt 224.0.0.252
23:20:14.207 192.168.1.78 ->239.255.255.250 IGMP Rpt 239.255.255.250
23:20:14.275 192.168.1.73 -> 224.0.0.251 IGMP Rpt 224.0.0.251
23:20:14.431 192.168.1.67 ->239.255.255.250 IGMP Rpt 239.255.255.250
23:20:14.628 192.168.1.74 -> 224.0.0.251 IGMP Rpt 224.0.0.251
23:20:14.658 192.168.1.74 -> 239.255.3.22 IGMP Rpt 239.255.3.22
23:20:14.823 192.168.1.84 -> 224.0.1.60 IGMP Rpt 224.0.1.60
23:20:15.142 192.168.1.84 ->239.255.255.250 IGMP Rpt 239.255.255.250
\Device\NPF_{97E738FB-7C6B-44A2-94E6-849711BE5FEA}
Description: Juniper Network Connect Virtual Adapter
\Device\NPF_{34300D3D-4A5E-4FFC-AAC3-858698ABE021}
Description: Microsoft
\Device\NPF_{A2831814-A4AF-4FE4-A8E4-88FAD0E560D4}
Description: Microsoft Corporation
Address Family Name: AF_INET
Address: 192.168.70.209
Netmask: 255.255.255.240
Broadcast Address: 255.255.255.255
IGMPv2 general query 192.168.70.209 -> 224.0.0.1
listening for responses ...
23:20:24.558 192.168.70.209 -> 224.0.0.251 IGMP Rpt 224.0.0.251
23:20:24.558 192.168.70.209 ->239.255.255.250 IGMP Rpt 239.255.255.250
Could you please help me out?
Thanks in advance:
Ben
Erm. For those that aren't networking engineers ... what are the IP addresses of the two Win10 boxes?
The 2 IP addresses:
192.168.1.72
192.168.1.78
Ben
Is there some sort of managed switch, or if either of the 72 or 78 machines is a VM, a hypervisor, that may be dropping packets? The "general failure" after a ping implies that there is either a misconfigured OS or there is something swallowing the ping. What is the network topology between the two machines?
Both are normal PC, no VM or other special things on them. Tghey both connected to a Sagemcom F@ast 5655v2 AC home gateway. Today, I tried one of the machines on another network and communication went there smoothly, so the problem is somewhere in the network.
Thanks,
Ben
Does the home gateway swallow UDP packets addressed to multicast addresses. Not uncommon.
Thanks, do you have any suggestion how to check it or how to fix it?
Thanks,
Ben