Re: Configs interfere with SSID deletion in connmanctl

On Thu, Feb 20, 2025 at 4:10 PM Grant Erickson <[email protected]> wrote:
>
> On Feb 14, 2025, at 7:39 AM, KeithG <[email protected]> wrote:
> >
> >
> > Is it intended behavior that when a *.config is present in
> > /var/lib/connman that connmanctl will refuse to delete the config?
> >
> > I have a config for my local SSID. What we do is upon boot: a script
> > looks for wifi info in a txt file in /boot/wifi. If one is there, we
> > create a *.config and put it in /var/lib/connman and when connman
> > starts, it will connect to that SSID. All good. Works as expected. If
> > I go to connmanctl and try to remove the config
> > connmanctl> config wifi_blah_blah --remove
> > Error wifi_blah_blah: Not supported
> >
> > Is there a requirement that the *.config must be named exactly as the
> > folder in /var/lib/connman for that SSID and then it will work? As it
> > is, we give it a name which is the "second blah".config (the hex
> > string conversion of the SSID name). Is the intention that we are
> > supposed to delete the *.config after our first connection to the SSID
> > and then let connman manage it? We do notice that when we delete the
> > *.config that connman automatically disconnects then deletes the
> > folder structure under /var/lib/conman.
>
> Keith,
>
> It is important to think of *.config and /var/lib/connman/<technology>_<ident> as distinct and separate things that are, likewise, administered distinctly and separately.
>
> I like to think of *.config as “provisions”. That is, a configuration provisioned by a user or system administrator for a network the system anticipates encountering at some time in the future. If the network is never encountered, then it lies dormant, in wait. When the network is encountered, it serves for automatically fulfilling information needed to connect to and create the associated network service that would otherwise be interactively gathered from a user or system administrator. Since the “provision" is created by a user or system administrator, bookending that, it can only be removed by a user or system administrator. In effect, it lives under but outside of the connman automatic administrative domain.
>
> /var/lib/connman/<technology>_<ident> are connman’s own, internal dynamic, mutable settings that both live under and inside the connman automatic administrative domain. If there is no *.config, then settings will be created for services automatically (Ethernet or Cellular) or with some user intervention / input (Wi-Fi). The format and administration of these settings is opaque outside of connman, accessible only by the D-Bus interface. When a service is removed (or mutated) using the connman D-Bus API (which includes connmanctl), these are the settings that are removed (or mutated). Any underlying *.config provision is untouched. While related, as we learned above, provisions are understood by connman but are not administered by it.
>
> I hope that helps!
>
> Best,
>
> Grant
>
> --
> Principal
> Nuovations
>
> [email protected]
> https://www.nuovations.com/
Grant,

Thanks! I now 'get it' as to why it was set up this way.

Keith