With this step now the device is publishing a mDNS service with name LXI Device and type _lxi._tcp.
Test steps
Note down the hostname of the DUT (Verdin) and disconnect the device from LAN
On another device (test equipment: it can be a laptop or any other device which have a running mDNS), change the hostname to the DUT hostname, and restart this device or the mDNS service, to use the new hostname as the mDNS hostname. This device should be there in the LAN
Now the DUT and the test equipment is having same hostname
Connect the DUT to the LAN
At this step I expect that, the DUT should change its hostname to new hostname, due to the hostname conflict. e.g., if abc was the previous hostname of the DUT, then new hostname should be abc-2.
This is not happening in the OS. I expect the avahi-daemon should do this procedure of changing the hostname.
But the interesting thing is, avahi-daemon will do this job, when I disabled the IPv6.
For disabling the IPv6 I’ve added the below lines in the /etc/sysctl.conf file, and applied the changes using sysctl -p command.
This same issue is happening on our Yocto build too. To make sure the issue is not because of some wrong network configuration on the Yocto build I tried with the basic OS from here.
With disabled IPv6, its working as expected, but I can’t disable the IPv6 for my application services. Are there any known issues with mDNS on this OS version.
I’ve tested the same in a Raspberry Pi. There even without disabling the IPv6, it works smoothly.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for reaching out with your question about mDNS hostname conflict resolution on your Verdin iMX8MP SOM with Torizon Core 5. It seems that the avahi-daemon is not resolving hostname conflicts as expected when IPv6 is enabled, which is indeed an unusual behavior.
Here are some steps you can take to troubleshoot and potentially resolve this issue without disabling IPv6:
Avahi Configuration: Check the Avahi configuration file located at /etc/avahi/avahi-daemon.conf. Ensure that the use-ipv6 setting is enabled by setting it to yes. This ensures that Avahi is configured to handle both IPv4 and IPv6.
Network Interface Setup: Verify that your network interfaces are properly configured to support both IPv4 and IPv6. Misconfigurations at the network level can sometimes lead to unexpected behavior.
Avahi Version: Make sure you are using the latest version of Avahi available for your Torizon Core version. Updates or patches might address specific issues related to IPv6.
Log Analysis: Examine the Avahi logs for any error messages or warnings that could provide more insight into the issue. You can view these logs using the command journalctl -u avahi-daemon.
Alternative Network Testing: If possible, test your setup on a different network environment to rule out any network-specific issues that might be affecting mDNS behavior.
The interaction between mDNS and IPv6 can sometimes lead to unexpected results due to network configurations or specific conditions. By following these steps, you should be able to diagnose and potentially resolve the problem.
I hope this helps, and please feel free to reach out if you have any further questions.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Avahi Configuration: The Avahi configuration looks good, and it’s the default which comes with the OS. It’s having the use-ipv6=yes line in the config file.
Network Interface Setup: Default from the OS
Avahi Version: 0.7 Default from the OS. On the Yocto we have the 0.8.
Log Analysis: Journal logs didn’t have any errors and warnings, with IPv6 enabled. By disabling the IPv6, I can see the hostname conflict information.
Also, what is the Avahi version from your Raspberry Pi?
Could you please perform the same test on the latest version of Torizon OS? It is currently Torizon OS 7, available here: Download Links | Toradex Developer Center. The idea here is that a more up-to-date OS (and more up-to-date avahi version) could simply solve it without investing to much time investigating.
The Raspberry Pi have the latest Avahi version (V0.8). I’ve tried in the Torizon OS 7. The expected conflict was not received even when I disabled the IPv6.
The tdx-info for Torizon OS 7:
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 6.6.54-7.1.0-g3493ccd66900 #1-Torizon SMP PREEMPT Tue Dec 17 21:04:41 UTC 2024
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo v t.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ost ree=/ostree/boot.1/torizon/500611918e07c8fe1cf9b3cc8f76327936d80d93ad461d3fe0da9 c30624ff84b/0
Distro name: NAME="Torizon OS"
Distro version: VERSION_ID=7.1.0-build.4
Distro variant: VARIANT="Docker"
Hostname: abi
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Boa rd
Toradex version: 0058 V1.1A
Serial number: 14773669
Processor arch: aarch64
------------------------------------------------------------
On my side, when I force the hostname collision without changing /etc/sysctl.conf, here is what I can see:
The PS1 stays the same as before (no -2 appended)
/etc/hostname stays the same (no -2 appended)
Output of hostnamectl stays the same (no -2 appended)
But When checking avahi’s logs, I get:
torizon@verdin-imx8mm-06827402:~$ journalctl -u avahi-daemon.service
Feb 13 18:31:32 verdin-imx8mm-06827402 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Found user 'avahi' (UID 987) and group 'avahi' (GID 989).
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Successfully dropped root privileges.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: avahi-daemon 0.8 starting up.
Feb 13 18:31:33 verdin-imx8mm-06827402 systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Successfully called chroot().
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Successfully dropped remaining capabilities.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: No service file found in /etc/avahi/services.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface lo.IPv6 with address ::1.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface lo.IPv6 for mDNS.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface lo.IPv4 for mDNS.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Network interface enumeration completed.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for ::1 on lo.*.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 127.0.0.1 on lo.IPv4.
Feb 13 18:31:33 verdin-imx8mm-06827402 avahi-daemon[481]: Server startup complete. Host name is verdin-imx8mm-06827402.local. Local service cookie is 199367820.
Feb 13 18:31:37 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface end0.IPv6 with address fe80::1a5a:3380:4a20:ff86.
Feb 13 18:31:37 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface end0.IPv6 for mDNS.
Feb 13 18:31:37 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for fe80::1a5a:3380:4a20:ff86 on end0.*.
Feb 13 18:31:38 verdin-imx8mm-06827402 avahi-daemon[481]: Leaving mDNS multicast group on interface end0.IPv6 with address fe80::1a5a:3380:4a20:ff86.
Feb 13 18:31:38 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface end0.IPv6 with address 2804:14d:80a5:8006:94a9:7fd4:5132:673b.
Feb 13 18:31:38 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 2804:14d:80a5:8006:94a9:7fd4:5132:673b on end0.*.
Feb 13 18:31:38 verdin-imx8mm-06827402 avahi-daemon[481]: Withdrawing address record for fe80::1a5a:3380:4a20:ff86 on end0.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface end0.IPv4 with address 192.168.0.150.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface end0.IPv4 for mDNS.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 192.168.0.150 on end0.IPv4.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Withdrawing address record for 192.168.0.150 on end0.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Withdrawing address record for ::1 on lo.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Withdrawing address record for 127.0.0.1 on lo.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Host name conflict, retrying with verdin-imx8mm-06827402-2
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 2804:14d:80a5:8006:94a9:7fd4:5132:673b on end0.*.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 192.168.0.150 on end0.IPv4.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for ::1 on lo.*.
Feb 13 18:31:39 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 127.0.0.1 on lo.IPv4.
Feb 13 18:31:40 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1.
Feb 13 18:31:40 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface docker0.IPv4 for mDNS.
Feb 13 18:31:40 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 172.17.0.1 on docker0.IPv4.
Feb 13 18:31:41 verdin-imx8mm-06827402 avahi-daemon[481]: Server startup complete. Host name is verdin-imx8mm-06827402-2.local. Local service cookie is 199367820.
Feb 13 18:31:42 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface br-45bec36b0ac0.IPv4 with address 172.18.0.1.
Feb 13 18:31:42 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface br-45bec36b0ac0.IPv4 for mDNS.
Feb 13 18:31:42 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for 172.18.0.1 on br-45bec36b0ac0.IPv4.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface br-45bec36b0ac0.IPv6 with address fe80::42:6fff:fe6d:98f4.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface br-45bec36b0ac0.IPv6 for mDNS.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for fe80::42:6fff:fe6d:98f4 on br-45bec36b0ac0.*.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: Joining mDNS multicast group on interface veth924d969.IPv6 with address fe80::d4d4:eeff:fe4d:afcc.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: New relevant interface veth924d969.IPv6 for mDNS.
Feb 13 18:31:46 verdin-imx8mm-06827402 avahi-daemon[481]: Registering new address record for fe80::d4d4:eeff:fe4d:afcc on veth924d969.*.
From the log, it is clear that the -2 was appended to the original hostname.
It is indeed the new hostname: from another machine in the same network, I can ping and SSH using the -2-appended hostname and the module will both respond the ping and be successfully accessed via SSH.
And you can see that I really didn’t change /etc/sysctl.conf on my side:
Could you please test SSH and ping on the -2 appended hostname on your side with the defaul /etc/sysctl.conf?
To be honest, I don’t know if there is some configuration needed in avahi to change the /etc/hostname (and PS1/hostnamectl). I will try to better understand it. If you have some hint on your side, please let us know
May I know your test method? How you force the hostname collision?
Maybe I missed in the previous conversation. That the collision is happening when we do force collision using another avahi based mDNS device. Where my test suite is a TSEP Kerberos, which have a Bonjour based mDNS. I’ve spoken with the TSEP technical team regarding this, and they confirmed that there is no issue with their test suit. Supporting to that confirmation, with a Raspberry Pi the hostname conflict is happening with TSEP Kerberos, and the Raspberry Pi Avahi journal logs looks same as yours. But while Torizon OS is missing with the log Host name conflict, retrying with verdin-imx8mm-06827402-2 (with enabled IPv6).
I will get all possible logs from Torizon OS 7, ASAP.
Verdin iMX8MM DL 1GB V1.1A (expand to see tdx-info and avahi version)
avahi-daemon 0.8
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 6.6.54-7.1.0-g3493ccd66900 #1-Torizon SMP PREEMPT Tue Dec 17 21:04:41 UTC 2024
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/28c6117959abbf7185a98daaa9ef3bef7020fdd7ea6dbaa0701fc0e45f2a38a2/0
Distro name: NAME="Torizon OS"
Distro version: VERSION_ID=7.1.0-build.4
Distro variant: VARIANT="Docker"
Hostname: verdin-imx8mm-06827402
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Mini on Verdin Development Board
Toradex version: 0057 V1.1A
Serial number: 06827402
Processor arch: aarch64
------------------------------------------------------------
Test procedure
Note down the hostname of the DUT (Verdin IMX8MM, running Avahi) and disconnect the device from LAN
On Verdin IMX8MP (running Avahi), change the hostname to the DUT hostname (sudo hostnamectl set-hostname "verdin-imx8mm-06827402" → check /etc/hostname), and restart this device or the mDNS service, to use the new hostname as the mDNS hostname. This device should be there in the LAN
Now the DUT and the test equipment is having same hostname
In my case, DUT’s Avahi does advertise verdin-imx8mm-06827402-2 as the hostname, as expected.
A nice way to observe DUT’s reaction to the hostname collision is starting the watch command below before connecting it to LAN. After connecting DUT to LAN, the -2 takes around 5 seconds to show up.
