Hi Patrik, 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.
At this point, the application on the first device can't produce a .config file for the second device. It can't copy one out of /var/log/connman/, as there is no .config file to copy. It can't extract all information necessary to build the file from scratch via the services API, as the WiFi PSK is obscured. To extract the PSK in this scenario, the application would need to root around in /var/lib/connman/wifi_*/, as Grant observed. One option is for the application on the first device to create a .config file based on the user's network credentials, instead of passing this information to connman via the services API. This seems like a poor solution, however, as the logic to create .config files is then duplicated between connman and the application. 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. 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? Thanks, Drew On Mon, Jul 28, 2014 at 5:14 AM, Patrik Flykt <patrik.fl...@linux.intel.com> wrote: > > Hi, > > On Fri, 2014-06-27 at 12:27 -0700, Grant Erickson wrote: > > Imagine another system, different from a mobile device, perhaps like > > the first that can communicate and authenticate with it out-of-band, > > based on some provided user authority. Over that channel, the first > > device would like to tell the second, "When you encounter this WiFi > > network, you may connect to it with these credentials.". > > This can be achieved with a properly set up .config file obtained over > the out-of-band channel. The .config file format is described in > doc/config-format.txt. > > > While you're correct that one could certainly root about int > > he /var/lib/connman directory and pull this, such a mechanism will not > > The .config files are the only ones in /var/lib/connman that users can > modify. As they are documented, they belong to the API and are not going > to change. > > > Cheers, > > Patrik > > _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
