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
