The communication problem between "linux" and "windows"

[gongqinpeng]

Hello , I want to configure "cyclonedds" under the "linux" and " windows" systems of two computers, but I find it's normal in one of these, I cannot communicate with the window system via the linux system. Thank you very much!

[t0ny-peng]

You may need to post more detail about how you compile, what version you compiled, the network setup, firewall if any, and the error message, if any?

Ubuntu <-> Windows communication worked for me before. You can enable detailed log tracing in the configuration XML file to find some clues.

[gongqinpeng]

Hello , the XML file is : <?xml version="1.0" encoding="UTF-8" ?&gt; <CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"&gt; &nbsp; &nbsp; <Domain Id="any"&gt; &nbsp; &nbsp; &nbsp; &nbsp; <General&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <Interfaces&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <NetworkInterface autodetermine="true" priority="default" multicast="true" /&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </Interfaces&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <AllowMulticast&gt;true</AllowMulticast&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <MaxMessageSize&gt;65500B</MaxMessageSize&gt; &nbsp; &nbsp; &nbsp; &nbsp; </General&gt; &nbsp; &nbsp; &nbsp; &nbsp; <Discovery&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <EnableTopicDiscoveryEndpoints&gt;true</EnableTopicDiscoveryEndpoints&gt; &nbsp; &nbsp; &nbsp; &nbsp; </Discovery&gt; &nbsp; &nbsp; &nbsp; &nbsp; <Internal&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <Watermarks&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <WhcHigh&gt;500kB</WhcHigh&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </Watermarks&gt; &nbsp; &nbsp; &nbsp; &nbsp; </Internal&gt; &nbsp; &nbsp; &nbsp; &nbsp; <Tracing&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <Verbosity&gt;config</Verbosity&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <OutputFile&gt;cdds.log.${CYCLONEDDS_PID}</OutputFile&gt; &nbsp; &nbsp; &nbsp; &nbsp; </Tracing&gt; &nbsp; &nbsp; </Domain&gt; </CycloneDDS&gt; &nbsp;and I am sure that the firewall is closed and network is normal, I can communicate between the Ubuntu <&gt; Ubuntu, but I cannot communicate window <&gt; window and Ubuntu <&gt; window. Our version is the latest version. &nbsp;Thank you very much!

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "eclipse-cyclonedds/cyclonedds" ***@***.***&gt;; 发送时间:&nbsp;2024年4月12日(星期五) 中午11:42 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [eclipse-cyclonedds/cyclonedds] The communication problem between "linux" and "windows" (Issue #1976) You may need to post more detail about how you compile, what version you compiled, the network setup, firewall if any, and the error message, if any? Ubuntu <-&gt; Windows communication worked for me before. You can enable detailed log tracing in the configuration XML file to find some clues. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt; qinpenggong ***@***.***

[t0ny-peng]

Not an CycloneDDS expert here. What I usually did to debug the application is to dump the trace log to a file and examine each line, compare the difference (in your case, trace log from Ubuntu and from Windows) and look for any inconsistency. Also, compile the application in debug mode and add breakpoints to where the log differs. It's been a looong time since I developed on Windows so sorry for not being able to offer further help.

[eboasson]

I can only confirm what @t0ny-peng writes, it almost always is the networking setup. I always first check:

1. firewall
2. selected network interface
3. if it really uses multicast — cdds.log should already tell you this with the configuration you use. On my macbook using loopback it says:

   1710844146.228084 [0]    4969711: udp initialized
   1710844146.228384 [0]    4969711: interfaces: lo0 udp/127.0.0.1(q1) en0 wireless udp/192.168.1.6(q9)
   1710844146.228399 [0]    4969711: lo0: presumed robust multicast support, use for everything
   1710844146.228410 [0]    4969711: selected interfaces: lo0 (index 1 priority 2 mc {spdp,asm,ssm})
   1710844146.228418 [0]    4969711: all interfaces allow spdp multicast, no peers defined: defaulting participant index to "none"
   1710844146.228432 [0]    4969711: ownip: udp/127.0.0.1
   1710844146.228440 [0]    4969711: extmask: invalid/0 (not applicable)
   1710844146.228446 [0]    4969711: SPDP MC: udp/239.255.0.1
   1710844146.228453 [0]    4969711: default MC: udp/239.255.0.1
   

   if it isn't using multicast, you'll see other messages.

If 1, 2 and 3 check out, you might want to verify that each machine at least receives "something" from the other. In the detailed trace (<Category>trace</Category>) that shows up like:

1710844146.232429 [0]       recv: HDR(110a7bc:12cabbf8:929c611e vendor 1.16) len 476 from udp/127.0.0.1:51911 to udp/127.0.0.1:57550@1

(obviously with different addresses). If there is no communication in at least one direction, go back to step 1 because then it really is something in the operating system or the network. Wireshark can be really useful in that case.

If one machine does discover the other, there'll be a line like:

1710844146.232513 [0] dq.builtin: SPDP ST0 110a7bc:12cabbf8:929c611e:1c1 bes fc3f NEW (0x00000000-0x0000002c-0x00000000-0x00000000-0x00000000 phantasie.local/0.11.0/Darwin/Darwin) (data udp/239.255.0.1:7401@1 udp/127.0.0.1:64670@1 meta udp/239.255.0.1:7400@1 udp/127.0.0.1:64670@1) QOS={user_data=31<"DDSPerf:0:48947:phantasie.local">,liveliness=0:10000000000,property_list={1:"__ProcessName":"ddsperf",1:"__Pid":"48947",1:"__Hostname":"phantasie.local"}:{}}

again, obviously details like GUIDs, addresses, names, etc. will be different. You could try grep 'SEDP.*NEW' cdds.log 🙂 (and/or have a look at https://cyclonedds.io/content/guides/tracefile.html).

If it does receive packets but doesn't have this "SPDP" line, then there is a small chance that it has something to do with #1943, which I merged recently. In you suspect that may be the case, rolling back to a commit just before that PR got merged would be something to try.

[gongqinpeng]

Thank you very much! I have modified the XML of the configuration, the "NetworkInterface name", and the Ubuntu communicate with Windows successful, thank you very much!

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "eclipse-cyclonedds/cyclonedds" ***@***.***&gt;; 发送时间:&nbsp;2024年4月12日(星期五) 下午3:28 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [eclipse-cyclonedds/cyclonedds] The communication problem between "linux" and "windows" (Issue #1976) I can only confirm what @t0ny-peng writes, it almost always is the networking setup. I always first check: firewall selected network interface if it really uses multicast — cdds.log should already tell you this with the configuration you use. On my macbook using loopback it says: 1710844146.228084 [0] 4969711: udp initialized 1710844146.228384 [0] 4969711: interfaces: lo0 udp/127.0.0.1(q1) en0 wireless udp/192.168.1.6(q9) 1710844146.228399 [0] 4969711: lo0: presumed robust multicast support, use for everything 1710844146.228410 [0] 4969711: selected interfaces: lo0 (index 1 priority 2 mc {spdp,asm,ssm}) 1710844146.228418 [0] 4969711: all interfaces allow spdp multicast, no peers defined: defaulting participant index to "none" 1710844146.228432 [0] 4969711: ownip: udp/127.0.0.1 1710844146.228440 [0] 4969711: extmask: invalid/0 (not applicable) 1710844146.228446 [0] 4969711: SPDP MC: udp/239.255.0.1 1710844146.228453 [0] 4969711: default MC: udp/239.255.0.1 if it isn't using multicast, you'll see other messages. If 1, 2 and 3 check out, you might want to verify that each machine at least receives "something" from the other. In the detailed trace (<Category&gt;trace</Category&gt;) that shows up like: 1710844146.232429 [0] recv: HDR(110a7bc:12cabbf8:929c611e vendor 1.16) len 476 from udp/127.0.0.1:51911 to ***@***.*** (obviously with different addresses). If there is no communication in at least one direction, go back to step 1 because then it really is something in the operating system or the network. Wireshark can be really useful in that case. If one machine does discover the other, there'll be a line like: 1710844146.232513 [0] dq.builtin: SPDP ST0 110a7bc:12cabbf8:929c611e:1c1 bes fc3f NEW (0x00000000-0x0000002c-0x00000000-0x00000000-0x00000000 phantasie.local/0.11.0/Darwin/Darwin) (data ***@***.*** ***@***.*** meta ***@***.*** ***@***.***) QOS={user_data=31<"DDSPerf:0:48947:phantasie.local"&gt;,liveliness=0:10000000000,property_list={1:"__ProcessName":"ddsperf",1:"__Pid":"48947",1:"__Hostname":"phantasie.local"}:{}} again, obviously details like GUIDs, addresses, names, etc. will be different. You could try grep 'SEDP.*NEW' cdds.log 🙂 (and/or have a look at https://cyclonedds.io/content/guides/tracefile.html). If it does receive packets but doesn't have this "SPDP" line, then there is a small chance that it has something to do with #1943, which I merged recently. In you suspect that may be the case, rolling back to a commit just before that PR got merged would be something to try. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt; qinpenggong ***@***.***