On Sun, May 26, 2019 at 01:29:23PM +0200, tormen(a)mail.ch wrote:
I wanted to kindly ask you if you could shed some light on this:
Because I am lost and I don't get it :(
There should be a way that a wireless profile connman uses can be
viewed or edited through a GUI, or not?
ConnMan exposes via D-Bus some information about the underlying
network configuration. On purpose not everything has been exposed via
the D-Bus API. The design idea here is not to expose unnecessary
things, keep it as simple as possible. While this works for some
users, not everyone is happy with it. That is why we added additional
ways to configure and provision ConnMan. While this works, it is far
from being perfect.
I suppose something like this should be considered for a ConnMan 2.x
This is really useful e.g. to check "auto-connect"
that off if you forgot to do that when creating the wireless profile).
The wireless password is something to be discussed. Ideally I as
connman user could choose to expose the passwords (e.g. shared key wpa2)
through it's API as well so that a tool like cmst can show me
the current setting (including passwords) used by connman.
Currently, ConnMan doesn't allow to read back the password via
D-Bus. The only reason why ConnMan stores the password is because
wpa_supplicant doesn't store it itself. If wpa_supplicant could save a
configuration ConnMan wouldn't store the password. All other daemons
are able to make a configuration persistent.
I am still new to connman. I know that you can use it with iwd and
wpa_supplicant. But ideally I would expect that connman uses a wireless
configuration that is agonostic to the actual tool used to do the
wireless setup. Is that the case?
Yes, ConnMan is designed to abstract the network configuration.
And if yes, then what do you think:
(a) Should there be a possibility for cmst to view and/or edit this
I can't speak for cmst, but I am really glad someones is working on
UIs for ConnMan!
(b) Does connman already offer interfaces (APIs?) for cmst to do so?
And if yes, which ones?
We have all API's documented in the doc folder. This includes how you
can do provisioning (read configuration) of services.