uftpd does not rejoin IPV6 multicast group

[Andreas B.]

Hi there,

I'm running the uftp client v4.9.5 on a large number of industrial embedded systems (Linux Kernel v4.9.11).
The clients are hierarchically meshed up by proprietary physical interface.

The client configuration is as following:

uftpd -x 3 -L /var/log/uftp.log -D /vol/misc/dest -t -M ff32::1:2:3 -I br-mgmt/6 -P /var/run/uftpd.pid -U $CLIENT_ID$

The interface br-mgmt the client is configured on, is a bridge interface and running IPv6 only.
For address configuration SLAAC is used, where a router advertisement daemon, located at the head-end
of the network, is in charge of announcing the corresponding IPv6 prefix.

What I have now observed is following:
The uftp client unpredictable drops the joined IPv6 multicast group for any reason.
This can be monitored by

ip -6 maddress show dev br-mgmt

And unfortunately, it does not re-join the group. Two other services, which have also
joined different multicast groups on the same interfaces are not showing this issue.

Are there any reasons why the uftp client should leave the multicast group either by itself or by external impacts?
Is it possible that the client will automatically rejoin the group without the need to restart the service?

Thanks,
Andreas

[Dennis Bush]

Andreas,

The client should keep the public multicast group up the whole time it is running. Are you perhaps using a private address that's the same as the public address? The code should account for this situation, but it's still best to use distinct addresses for public and private so clients not participating in a given group don't get packets they don't need.

Regards,
Dennis

[Andreas B.]

Hi Dennis,

thanks for your answer.

I'm using distinct addresses for the private and public part of the commuication, like mentioned in the uftp examples.

uftp -x3 -f -M ff32::1:2:3 -P ff32::4:5:6 -I enp1s0f0.1001/6 -R 75 FILE_NAME

I tested non-SSM compliant addresses (ff02::, ff05::, etc.) as well with the same result.

My other services joining groups on distinct ASM compliant addresses (ff12::), bound on the same interface. These services are running as expected, whereas the uftp clients are unpredictable dropped. Which means that it happens on all systems at different times, without any correlation to any system state changes.

At first, I suspected SLAAC. So I changed to a static IPv6 configuration, but without any improvement. Unfortunately, I can not change to IPv4 and test the behavior.

As a workaround, I'm currently running a cronjob every 5 minutes, checking that the public address is still joined, otherwise the uftp client services is restarted.

Regards,
Andreas