> Why don't you just remove the settings file and restart
oFono handles many other services so restarting would have undesirable effects.
For a moment clients would think there is no telephony at all: no SIM,
no cellular signal strength, no voice/emergency calls, no SIM ATK etc.
Which is probably OK given that you're resetting cellular settings.
Unless you expect the user to know / have control over very fine-grained
>> Deactivation of the context is obviously mandatory. The
reasoning for placing
>> this into ofono is handling client requests consistently and avoiding race
>> conditions. Using this approach ofono does not re-activate the context,
>> done by ConnMan or whatever connection manger the system uses.
> I'm not so sure that this is a good idea. A 'live' reset of the
> settings just seems wrong to me. Why would you ever want to do that
> anyway? If something is working, why bother resetting the settings?
Generally speaking I agree with the point of view. The main point was
not the 'live' part, but to allow running provisioning again, e.g. if
user has set wrong ones.
Then this has to be done with Powered = False as a prerequisite. And
you need some way to tell ConnMan what is happening and why. Since
someone still has to go in and activate the new contexts afterwards.
FYI a MMS context may be active using a correct APN but messages
flow due to a wrong proxy. In such a case context remains active for
I don't get it, if the proxy is wrong, it must have been provisioned
that way. How is re-provisioning going to help? Either way, it sounds
like you want the UI to reset a particular context's settings, not
> oFono supports arbitrary number of contexts, so your UI can always add
> more. So if you need to re-provision, let your UI handle this. The UI
> should be capable of reading the provisioning database anyway in order
> to handle duplicates, etc.
When ofono already implements the initial provisioning logic it is not
tempting to duplicate it but instead trigger it again.
Not tempting, no. Provisioning is there to handle simple cases. E.g.
user receives new device, turns it on and gets connected. If you want
the user to mess with the settings, or if your database might contain
ambiguous information, then you need to write a proper UI. One that can
read the provisioning database as well and present choices to the user.
(A more suitable name for the new method could be
If reverting provisioned settings is done by creating a new empty
context, one would still want to run ofono provisioning for that
(ofono restart not an option).
The problem is there's really no mapping between what the provisioning
database returns and what the settings are right now. You can sort of
kludge around by comparing the context type, but you might be
over-writing the wrong context.
The better way is to wipe all existing settings and re-populate. But
that would require quite a bit of ContextRemoved, ContextAdded signals
to keep the clients consistent.
Might be easier to just re-boot the gprs atom.