Hello!
I think I have a bug with the Torizon BSP on the Dahlia/Maivin hardware. What I’m seeing is that, when I enable the wireless mlan0 interface, it works, and I can use the mDNS advertised hostname to connect over the wireless interface for about 8 minutes. Then, when I follow the systemd logs, the access point interface uap0 cycles,
Jul 24 22:54:05 verdin-imx8mp-XXXXXXXX systemd-networkd[648]: uap0: Link DOWN
Jul 24 22:54:05 verdin-imx8mp-XXXXXXXX NetworkManager[654]: [1690239245.9011] device (uap0): set-hw-addr: set MAC address to D6:C4:59:5E:03:67 (scanning)
Jul 24 22:54:05 verdin-imx8mp-XXXXXXXX systemd-networkd[648]: uap0: Link UP
Jul 24 22:54:05 verdin-imx8mp-XXXXXXXX NetworkManager[654]: [1690239245.9040] device (uap0): supplicant interface state: inactive → interface_disabled
Jul 24 22:54:06 verdin-imx8mp-XXXXXXXX NetworkManager[654]: [1690239246.0348] device (uap0): supplicant interface state: interface_disabled → inactive
the mlan0 interface loses the mDNS advertisements, and I can no longer use the hostname to ping/SSH the device; though the IP address still works. If I restart systemd-resolved or NetworkManager, the mDNS advertisements return, for 8 mins, before the uap0 cycles again. As a work-around, I’ve stopped NetworkManager from managing the uap0 interface by creating the following file:
torizon@verdin-imx8mp-XXXXXXXX:~$ cat /etc/NetworkManager/conf.d/99-unmanaged-uap0.conf
[keyfile]
unmanaged-devices=interface-name:uap0
Hardware / Software Environment
Verdin iMX8MP
Dahlia Carrier Board (Maivin)
Linux BSP Kirkstone-based
Greetings @kristopher,
Based on your description it sounds like there’s some sort of conflict between NetworkManager and systemd-networkd here. Just to confirm once you did this:
As a work-around, I’ve stopped NetworkManager from managing the uap0 interface by creating the following file:
Was the connection now “stable” for a longer period of time?
Also just to understand what is your use-case here? Do you plan to use both the wireless (mlan0) and access point (uap0) interfaces simultaneously?
Best Regards,
Jeremias
I haven’t tested it across longer periods of time – just that removing the uap0 from Network Manager seems to address the issue.
The use case is to only use mlan0 as a wireless “client” interface, and to not use uap0 at all. The larger concerns are the overall stability of mDNS, which is a vital service, and the lack of logging or other feedback mechanisms from the device regarding the service. That snippet is the entirety of the journalctl output at the time – there is nothing noting that mDNS service has been affected, much less terminated.
Also, thank you for your quick reply!
The use case is to only use mlan0 as a wireless “client” interface, and to not use uap0 at all.
Okay that’s good to know then. For the time being just stick with your workaround and let me know if there’s still stability issues with your workaround.
This behavior hasn’t been reported before so I’ll need some time do a further investigation. I’ll let you know if I uncover anything or if I need more information.
As a final question for now, I see you mentioned this was on the Kirkstone/6.X.Y version of TorizonCore, yes? if you have time can you see if this issue happens to you on Dunfell/5.7.Y TorizonCore?
Best Regards,
Jeremias
Small update.
Good news I was able to reproduce this behavior exactly as you described it. Bad news I can’t seem to find any logs that suggest any kind of error or warning. It’s almost as if mDNS just silently stopped working.
Interestingly this doesn’t seem to happen on TorizonCore 5.7.2, at least with my brief test. Therefore this seems to be some kind of regression from 5.7.2 to 6.X, which helps narrow it down a bit.
Alright I think I have enough information I’ll go ahead and report this to our team for a deeper investigation.
Best Regards,
Jeremias
Jeremias, I’m sorry: I don’t have a pre-Kirkstone build at hand. However, you can reproduce this exactly as I described which I can completely commiserate with you.
As said before I’ve already created a ticket about this with our team for further action. I’ll try and notify you when something notable happens here, hopefully a fix or solution of some kind.
Best Regards,
Jeremias
