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
Jeremias, has this issue been addressed or closed?
Hi @kristopher,
This issue has not been directly addressed yet by our team. That said, our team has been considering adding a default configuration to Torizon OS that would stop NetworkManager from managing the uap0 interface, which was your workaround for this issue. The reason the team is considering this is not solely because of the issue here. It’s because we’ve had various reports that the uap0 interface misbehaves in various complex ways when managed directly by NetworkManager.
If the team decides on this course of action (which does seem likely at this time), then your issue here would be indirectly addressed.
Would this be sufficient for you?
From what I recall of our discussion here, this “workaround” was working fine for your system since you were not using the uap0 interface anyways. Is that still the case, or has something changed since last we discussed this issue?
Best Regards,
Jeremias
1 Like
Thank you for your prompt reply! 
If your solution is just to formalize the workaround that disables the uap0 interface, then I guess we’ll be ahead of the curve. The workaround is fine – it’s just that while (not) implementing it, we noted the issue was still there and we wondered if we’ve missed something regarding a more official fix from your side.
The workaround is fine
Perfect, thanks for checking-in.
Best Regards,
Jeremias
1 Like
Hi @kristopher,
Just to inform you our team has gone through with formalizing the workaround/fix that we discussed: networkmanager: unmanage any uap interface · torizon/meta-toradex-torizon@0cc3287 · GitHub
As you can see this was just recently merged, so it’s only currently available on recent nightly images of Torizon OS. But, it should be in every future release going forward from this point.
Best Regards,
Jeremias
