bug: beacon incorrectly changes ethernet domain names when choosing a custom mDNS Hostname
Bug description
By default the ethernet interface is accessible via blueos.local, blueos-ethernet.local, and companion.local.
After configuring a custom mDNS hostname the defaults get ignored and overwritten, after which it's only possible to access the ethernet interface via blueos.local and <custom>.local, which I believe (for consistency with the defaults) should instead be blueos.local, <custom>-ethernet.local, companion.local, and possibly <custom>.local.
A pretty straightforward implementation would be to replace blueos with <custom> in each of the strings, and then if blueos is not in the list anymore append it.
Steps to reproduce
- Open a fresh install of BlueOS, or delete the beacon configs from the File Browser and restart the core container
- Access BlueOS via
blueos-ethernet.localorcompanion.local - Edit Vehicle Details in some way (even just changing the Vehicle Name still triggers the hostname overwrite)
- The page is no longer accessible, and the new hostname cannot be used with the
-ethernetsuffix
Primary pain point(s)
Intended behaviour doesn't work, and failing to connect to the interface is a critical issue, especially for users who don't know the default interface names that are always available (e.g. blueos-avahi.local).
Additional context
#1001 is another beacon configuration issue, although I don't believe they're related (but it might be worth trying to fix both at the same time).
Prerequisites
- [X] I have checked to make sure that a similar request has not already been filed or fixed.