Hi Danny, > > > I have question about why immutable is set in provision. > > > Based on immutable, EAP provision cannot remove_service, change ip > > > configuration method (e.g. manual IP set up). > > > > > > Could I have any reason? > > > provisioned services are actually under external control. They are by > > definition immutable. If you wanna remove them, then this should be done by > > the external entity that installed them. > > Do your "external entity" mean such as deleting configuration directly?
essentially yes. If you have some external provisioning daemon or similar, we could also make ConnMan listen to it, but that are just details. The fundamental point is that with provisioning the piece that puts it in place is also responsible for deleting it. You have to keep the symmetric behavior here. Otherwise you get into all sorts of weird problems and explaining this to the end-user will fail. > > In theory provisioned services can also have user controllable fields. > > For example when talking about EAP with TTLS we could choose to not > > provision the password and in this case it will be asked via the agent from > > the user. So there are certain fields that provisioning might leave out for > > security reasons. But generally speaking it should be known what your > > network setup is. Provisioning EAP and then allowing manual IP > > configuration does not sound like valid use case. If the IP assignment is > > static, then a static IP would have been provisioned in the first place. > > > I think that IP assignment has been provisioned at first, you are right. It's > not good example. > Do you think provisioned service always auto-connectable? Impossible to > remove? > > If I want to connect generic EAP (e.g. TTLS or AKA/SIM), do you think which > agent API or provision API is proper? So lets take one step back. One question to always ask is how much and which questions you can ask to a normal user that they can answer without calling an expert. And that is how the ConnMan API is designed. We only will forward questions to the agent (aka the UI of the user) that he/she can answer. When it comes to certificates or other complex security details, then the normal user is just fully lost. We can not do that. Things like pre-shared-keys, usernames, passwords etc. work. So if you do pure TTLS with just username/password and we can verify the certificates, then you should just be able to click Connect like you do for PSK. And instead of a PSK, you get asked for username/password. For AKA/SIM, you better have the network operator provisioned this properly. Since that one should not involve any user interaction at all. They really nasty part with AKA/SIM is that their is no real standard to select the SSID you are connecting to. The model of using WISPr 2.0 with EAP over HTTPS is a bit more cleaner since the WISPr model gives you context of what network you are. ConnMan right now only supports WISPr 1.0 since we have not yet seen 2.0 hotspots deployed at all. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
