hello, we found a problem in using updcast in a context of multi-routers when the rdv-addr is not multicast. Indeed, in this case, the multicast ttl must be greater than 1 (--ttl). But it is only assign during the processing of rdv-addr and only if rdv-addr is a multicast IP : udps-negotiate.c: /* Only do the following if controlMcastAddr is indeed an mcast address ... */ if(isMcastAddress(&net_config->controlMcastAddr)) { setMcastDestination(sock[0], net_config->net_if, &net_config->controlMcastAddr); setTtl(sock[0], net_config->ttl); But it is not assign during the processing of data-addr : udps-negotiate.c: if(isMcastAddress(&net_config->dataMcastAddr)) setMcastDestination(sock, net_config->net_if, &net_config->dataMcastAddr); Therefore, if rdv-addr is unicast then TTL remains to 1. So I suggest to patch the code this way : - if(isMcastAddress(&net_config->dataMcastAddr)) + if(isMcastAddress(&net_config->dataMcastAddr)) { setMcastDestination(sock, net_config->net_if, &net_config->dataMcastAddr); + setTtl(sock, net_config->ttl); + } Best regards, -- Julien Soula, Ingenieur Reseau, DSI/ULR2694, Universite de Lille, tel (0)3 20 62 34 55
Hi, On 17/04/2023 19:58, julien soula wrote:
hello,
we found a problem in using updcast in a context of multi-routers when the rdv-addr is not multicast.
Indeed, in this case, the multicast ttl must be greater than 1 (--ttl). But it is only assign during the processing of rdv-addr and only if rdv-addr is a multicast IP :
Thanks for the patch, this is now fixed in the newly released udpcast 20230924. This version also no longer uses 232.0.0.0/8 addresses as data multicast addresses by default (these are Source-specific multicast, which was actually not properly supported), and actually adds support for SSM. This might have been another stumbling block for non-local multicasts. Regards, Alain
participants (2)
-
Alain Knaff -
julien soula