Hi,
On Wed, 2014-07-30 at 14:55 -0700, Drew Stebbins wrote:
> There's a chicken-and-egg problem in the use case Grant mentioned
> which unfortunately can't be solved with .config file passing. In the
> presented use case, the user selects and authenticates to a network
> when they set up the first device. The application instructs connman
> to connect to the specified network with the given credentials via the
> services API. Once a connection is made, connman saves its
> configuration for this network somewhere in /var/lib/connman/wifi_*/,
> but ***does not*** create a .config file with this information.
So the use case was that the user him/herself sets up the network and
thus it's not initially provided out-of-band.
> At this point, the application on the first device can't produce
> a .config file for the second device.
Why not? It's just a simple matter of reading doc/config-format.txt and
writing code to do it.
> This seems like a poor solution, however, as the logic to
> create .config files is then duplicated between connman and the
> application.
ConnMan does not have any code for writing .config files, so there is no
code to duplicate.
> Also, any application which may need to retrieve a service's PSK in
> the future is forced to use file I/O rather than the services API to
> inform connman about preferred services.
Parsing a .config file is the only option to retrieve a passphrase as
the passphrase is not available via D-Bus in the first place.
> Also note that the second device might not even run connman (or Linux,
> for that matter). This means that to provision the second device, if
> the WiFi PSK is obscured via the services API, and if the application
> creates a .config file based on the user's input, then the application
> needs logic to parse .config files as well as create them. At this
> point, the application is interacting with connman more through file
> I/O than through D-Bus. It would be easier for the application (and
> application developers :)) if all necessary information to provision a
> new device could be retrieved from connman via the services API.
>
> What do you think?
You are actually trying to solve a configuration problem, not a ConnMan
related one. I'd start off by check something like
https://01.org/cpclient , continuing by looking at the data format used
for WiFi in NFC, and expanding my knowledge into other configuration and
information syncing protocols. If the data format needs to be shared
between other non-ConnMan devices, the generic solutions are the ones
you want to look for. Converting the OS agnostic WiFi configuration data
to a format understood by ConnMan will then be the easiest of the
problems at hand.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
