4:20 p.m.
Hi,
I'm looking at how I'm creating and using internet contexts to make
sure I'm not missing any problem cases, and I feel like I don't have
much feedback on what is happening and what possibly scenarios I
should be ready for. Dennis explained the ConnectionManager "life
time" last week which helped a lot (thanks) but I'm still struggling.
I've listed some steps that may happen from user/GUI point of view and
the questions I have (some are connman related but I think this is
still the better list):
* Modem with ConnectionManager appears
A ConnectionContext may have been created automatically or not. Under
what circumstances does this happen? E.g. If the mobile broadband db
contains several plans for a MNC/MCC does ofono try them until one
works or is the selection left to user? Are there checks to make sure
the created context is valid for the network?
* If a ConnectionContext does not appear, UI/user may create one.
using ConnectionManager.AddContext() and
ConnectionContext.SetProperty().
Are there checks at this point to ensure that the created context is
valid and should work? If not, is there anythign I can do to check
context validity?
* Connman exposes a cellular service
What are the conditions for this to happen? If connman exposes a
service, should that "Just work" (with normal caveats about internet
connections) or does it appear for any context that has been created?
* Finally, user can connect the cellular service exposed by connman
If the connection with a cellular service fails, is there anything
else than "Error=connect-failed" to work with? What are the potential
reasons for this -- is it just the normal issues with any network
connection, or can e.g. broken APN settings be a reason for failure at
this point?
In case background helps to understand it, this uncertainty came to be
from two issues (possibly related ones):
1. a tester is telling me nothing happens when he selects his plan
using dawati networks panel (ofono is 1.0 so automatic context
creation does not work), in other words the service isn't appearing in
connman. Now, I know how to start digging to the specific problem in
this case, but I'd like to make sure I'm handling all the relevant
error cases... What are the possible points of failure in this? Is it
just the method calls in ConnectionManager and ConnectionContext plus
Connman Service.Error after trying to connect to the service?
2. I've been testing ofono 1.4 and it seems I can succesfully create a
context with any values of APN/username/password and a connman service
will appear. Is this supposed to happen? (Calling Connect() on this
service will timeout and in the end set "Error=connect-failed", which
is to be expected)
- Jussi
3:03 p.m.
Hi Jussi,
On 02/21/2012 09:20 AM, Jussi Kukkonen wrote:
Hi,
I'm looking at how I'm creating and using internet contexts to make
sure I'm not missing any problem cases, and I feel like I don't have
much feedback on what is happening and what possibly scenarios I
should be ready for. Dennis explained the ConnectionManager "life
time" last week which helped a lot (thanks) but I'm still struggling.
I've listed some steps that may happen from user/GUI point of view and
the questions I have (some are connman related but I think this is
still the better list):
* Modem with ConnectionManager appears
A ConnectionContext may have been created automatically or not. Under
what circumstances does this happen? E.g. If the mobile broadband db
contains several plans for a MNC/MCC does ofono try them until one
works or is the selection left to user? Are there checks to make sure
the created context is valid for the network?
Actually this is really rather straight forward.
1. oFono obtains the IMSI from the Sim Card, this is a unique identifier
of the subscriber.
2. If the IMSI has not been seen before (e.g. a new never before sim
card is inserted) proceed to step 2a.
2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any
provisioning plugins to provide context information. The contract
between the provisioning plugin and oFono is that the information
provided must be unique. E.g. if there are any conflicts, or multiple
matches for a given mcc/mnc/spn then provisioning should fail.
Successful provisioning results in a set of contexts being created
before ConnectionManager interface is registered.
2b. If provisioning fails or mcc/mnc information is not known (e.g.
inadequate modem driver support) then a single, default, empty context
is created.
3. If the IMSI has been seen before, then any contexts created
previously are loaded from the IMSI-keyed storage. This includes the
unprovisioned 'default, empty context' if it hasn't been provisioned
previously.
So to sum up, from a UI point of view, you only need to care about
provisioning if the UI detects a single, empty context of type
'internet' with empty APN/username/password.
And no, there is absolutely no way to know whether a given context
settings are valid, but a good indication would be that a context
activation fails.
* If a ConnectionContext does not appear, UI/user may create one.
using ConnectionManager.AddContext() and
ConnectionContext.SetProperty().
Are there checks at this point to ensure that the created context is
valid and should work? If not, is there anythign I can do to check
context validity?
Not really
* Connman exposes a cellular service
What are the conditions for this to happen? If connman exposes a
service, should that "Just work" (with normal caveats about internet
connections) or does it appear for any context that has been created?
Connman only cares about internet contexts, and its services are
populated from the same ConnectionManager context list. There are no
further filtering rules other than the context type.
* Finally, user can connect the cellular service exposed by connman
If the connection with a cellular service fails, is there anything
else than "Error=connect-failed" to work with? What are the potential
not at this time
reasons for this -- is it just the normal issues with any network
connection, or can e.g. broken APN settings be a reason for failure at
this point?
Yes, broken APN settings can and do cause connection failures.
In case background helps to understand it, this uncertainty came to be
from two issues (possibly related ones):
1. a tester is telling me nothing happens when he selects his plan
using dawati networks panel (ofono is 1.0 so automatic context
creation does not work), in other words the service isn't appearing in
connman. Now, I know how to start digging to the specific problem in
this case, but I'd like to make sure I'm handling all the relevant
error cases... What are the possible points of failure in this? Is it
just the method calls in ConnectionManager and ConnectionContext plus
Connman Service.Error after trying to connect to the service?
If the service isn't appearing, then likely the context is not being
created properly...
2. I've been testing ofono 1.4 and it seems I can succesfully
create a
context with any values of APN/username/password and a connman service
will appear. Is this supposed to happen? (Calling Connect() on this
service will timeout and in the end set "Error=connect-failed", which
is to be expected)
Yes, this is supposed to happen. It is rather unfortunate that the user
has to know this information, however at this time we have not heard /
seen any standard for provisioning context settings other than the
widely used approach of consulting an external database. This approach
still requires user intervention a lot of times due to varying carrier
plans.
Regards,
-Denis
10:58 a.m.
On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
Hi Jussi,
Hi, thanks for clarification, it helps a lot.
On 02/21/2012 09:20 AM, Jussi Kukkonen wrote:
[clip]
> * Modem with ConnectionManager appears
> A ConnectionContext may have been created automatically or not. Under
> what circumstances does this happen? E.g. If the mobile broadband db
> contains several plans for a MNC/MCC does ofono try them until one
> works or is the selection left to user? Are there checks to make sure
> the created context is valid for the network?
Actually this is really rather straight forward.
1. oFono obtains the IMSI from the Sim Card, this is a unique identifier
of the subscriber.
2. If the IMSI has not been seen before (e.g. a new never before sim
card is inserted) proceed to step 2a.
2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any
provisioning plugins to provide context information. The contract
between the provisioning plugin and oFono is that the information
provided must be unique. E.g. if there are any conflicts, or multiple
matches for a given mcc/mnc/spn then provisioning should fail.
Successful provisioning results in a set of contexts being created
before ConnectionManager interface is registered.
2b. If provisioning fails or mcc/mnc information is not known (e.g.
inadequate modem driver support) then a single, default, empty context
is created.
3. If the IMSI has been seen before, then any contexts created
previously are loaded from the IMSI-keyed storage. This includes the
unprovisioned 'default, empty context' if it hasn't been provisioned
previously.
So to sum up, from a UI point of view, you only need to care about
provisioning if the UI detects a single, empty context of type
'internet' with empty APN/username/password.
or if the user explicitly tells me he wants to mess the context up
manually -- I will have to provide this possibility at all times if
there's no way of knowing whether specific settings are considered
valid by the network.
And no, there is absolutely no way to know whether a given context
settings are valid, but a good indication would be that a context
activation fails.
Aha... would you consider it a good/bad idea if a configuration UI
activated/deactivated the context after modifications to check for
this? This could be useful to say "We couldn't connect to the network
with these settings, would you like try another configuration?"
- Jussi
10:19 a.m.
Hi Jussi,
On 02/22/2012 03:58 AM, Jussi Kukkonen wrote:
On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior
<denkenz(a)gmail.com> wrote:
> Hi Jussi,
Hi, thanks for clarification, it helps a lot.
> On 02/21/2012 09:20 AM, Jussi Kukkonen wrote:
[clip]
>> * Modem with ConnectionManager appears
>> A ConnectionContext may have been created automatically or not. Under
>> what circumstances does this happen? E.g. If the mobile broadband db
>> contains several plans for a MNC/MCC does ofono try them until one
>> works or is the selection left to user? Are there checks to make sure
>> the created context is valid for the network?
>
> Actually this is really rather straight forward.
> 1. oFono obtains the IMSI from the Sim Card, this is a unique identifier
> of the subscriber.
> 2. If the IMSI has not been seen before (e.g. a new never before sim
> card is inserted) proceed to step 2a.
> 2a. oFono obtains MCC/MNC & SPN from the SIM file system, and asks any
> provisioning plugins to provide context information. The contract
> between the provisioning plugin and oFono is that the information
> provided must be unique. E.g. if there are any conflicts, or multiple
> matches for a given mcc/mnc/spn then provisioning should fail.
> Successful provisioning results in a set of contexts being created
> before ConnectionManager interface is registered.
> 2b. If provisioning fails or mcc/mnc information is not known (e.g.
> inadequate modem driver support) then a single, default, empty context
> is created.
> 3. If the IMSI has been seen before, then any contexts created
> previously are loaded from the IMSI-keyed storage. This includes the
> unprovisioned 'default, empty context' if it hasn't been provisioned
> previously.
> So to sum up, from a UI point of view, you only need to care about
> provisioning if the UI detects a single, empty context of type
> 'internet' with empty APN/username/password.
or if the user explicitly tells me he wants to mess the context up
manually -- I will have to provide this possibility at all times if
there's no way of knowing whether specific settings are considered
valid by the network.
Yep, sounds good.
> And no, there is absolutely no way to know whether a given context
> settings are valid, but a good indication would be that a context
> activation fails.
Aha... would you consider it a good/bad idea if a configuration UI
activated/deactivated the context after modifications to check for
this? This could be useful to say "We couldn't connect to the network
with these settings, would you like try another configuration?"
I'm generally in favor of not over-complicating this, but instead
relying on the provisioning data as much as possible. Look at iOS for a
good example, the user doesn't have any UI to edit context settings, it
is all provisioned using carrier profiles. Granted, the provisioning
database in use is a little bit better than what
mobile-broadband-provider-info provides, so some way to manually enter
details would still be required in our case; however we should strive to
make this as rarely used as possible.
What you suggest is a good idea, but might be overkill...
Regards,
-Denis
12:55 p.m.
Hi Dennis,
On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior <denkenz(a)gmail.com> wrote:
>> And no, there is absolutely no way to know whether a given
context
>> settings are valid, but a good indication would be that a context
>> activation fails.
>
> Aha... would you consider it a good/bad idea if a configuration UI
> activated/deactivated the context after modifications to check for
> this? This could be useful to say "We couldn't connect to the network
> with these settings, would you like try another configuration?"
>
I'm generally in favor of not over-complicating this, but instead
relying on the provisioning data as much as possible.
Well... we do that pretty well already, right? ofono autoconfigures if
there's a single match for the MMC/MNC. If there are several matches,
my 3G wizard consists of a single Dropdown list with the plans and a
OK-button.
I'm trying to improve the two problem cases:
1. user has to run 3G wizard and makes poor selections
2. There's a HW problem
As far as I can see the only way to do that is to fail as early as
possible. Currently we fail as late as possible and that's a confusing
user experience.
Look at iOS for a
good example, the user doesn't have any UI to edit context settings, it
is all provisioned using carrier profiles. Granted, the provisioning
database in use is a little bit better than what
mobile-broadband-provider-info provides, so some way to manually enter
details would still be required in our case; however we should strive to
make this as rarely used as possible.
What you suggest is a good idea, but might be overkill...
Since we have to let the user make a choice on something he does not
understand, I don't see good alternatives: currently we do the worst
possible thing: claim that everything is ok (by accepting the APN
settings and even showing the cellular service) and then later fail
when connecting -- and user has absolutely no way of knowing what the
failure was about*. I'll gladly take suggestions for simpler solutions
that lead to a UI that isn't confusing when things go wrong.
Jussi
*) emphasized by https://bugs.meego.com/show_bug.cgi?id=24943: connman
cell service state never seems to go to "failure".
6:12 a.m.
Hi Jussi,
On 02/24/2012 05:55 AM, Jussi Kukkonen wrote:
Hi Dennis,
On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior <denkenz(a)gmail.com> wrote:
>>> And no, there is absolutely no way to know whether a given context
>>> settings are valid, but a good indication would be that a context
>>> activation fails.
>>
>> Aha... would you consider it a good/bad idea if a configuration UI
>> activated/deactivated the context after modifications to check for
>> this? This could be useful to say "We couldn't connect to the network
>> with these settings, would you like try another configuration?"
>>
>
> I'm generally in favor of not over-complicating this, but instead
> relying on the provisioning data as much as possible.
Well... we do that pretty well already, right? ofono autoconfigures if
there's a single match for the MMC/MNC. If there are several matches,
my 3G wizard consists of a single Dropdown list with the plans and a
OK-button.
I'm trying to improve the two problem cases:
1. user has to run 3G wizard and makes poor selections
2. There's a HW problem
As far as I can see the only way to do that is to fail as early as
possible. Currently we fail as late as possible and that's a confusing
user experience.
I don't see how you are ever going to fix the HW problem part with a
better 3G settings wizard. If it doesn't work, no amount of helpful UIs
will make it work.
And if the user is entering information without good understanding of
the questions he's answering then either the provisioning database needs
to be updated or we should be asking better questions.
Of course, preferably we shouldn't even ask the user any questions if
possible ;)
> Look at iOS for a
> good example, the user doesn't have any UI to edit context settings, it
> is all provisioned using carrier profiles. Granted, the provisioning
> database in use is a little bit better than what
> mobile-broadband-provider-info provides, so some way to manually enter
> details would still be required in our case; however we should strive to
> make this as rarely used as possible.
>
> What you suggest is a good idea, but might be overkill...
Since we have to let the user make a choice on something he does not
understand, I don't see good alternatives: currently we do the worst
possible thing: claim that everything is ok (by accepting the APN
settings and even showing the cellular service) and then later fail
when connecting -- and user has absolutely no way of knowing what the
failure was about*. I'll gladly take suggestions for simpler solutions
that lead to a UI that isn't confusing when things go wrong.
If the user doesn't understand the choices he's making, then no amount
of helpful UIs will help here. Imagine you walk into a store with a
very helpful salesman, unfortunately you're speaking a different
language. If you don't have a very good idea of what you're looking
for, there's nothing he can do to help you.
My point here is that we should re-examine what we can do to make
provisioning more fool proof, rather than trying to band-aid a settings
UI that is inherently not understandable to anyone who isn't a GSM geek.
Regards,
-Denis
5:13 p.m.
On Fri, Feb 24, 2012 at 7:12 AM, Denis Kenzior <denkenz(a)gmail.com> wrote:
> I'm trying to improve the two problem cases:
> 1. user has to run 3G wizard and makes poor selections
> 2. There's a HW problem
> As far as I can see the only way to do that is to fail as early as
> possible. Currently we fail as late as possible and that's a confusing
> user experience.
I don't see how you are ever going to fix the HW problem part with a
better 3G settings wizard. If it doesn't work, no amount of helpful UIs
will make it work.
User experience issues have more shades of grey than middleware
issues... Failing early and clearly is significantly better UX than
failing but leading the user to believe things work. I'm not "fixing"
HW problems any more than I'm "fixing" connman crashes in my UI --
both are still events I'd rather handle (witihin limits) if that makes
the UX better.
And if the user is entering information without good understanding
of
the questions he's answering then either the provisioning database needs
to be updated or we should be asking better questions.
Of course, preferably we shouldn't even ask the user any questions if
possible ;)
We are in total agreement. I will gladly remove this whole UI when you
or someone else with knowledge on this tells me that ofono + mbpi can
handle things. Likewise, if you tell me I can drop the manual settings
part and that won't harm many users, I will do it in a heart beat.
>> Look at iOS for a
>> good example, the user doesn't have any UI to edit context settings, it
>> is all provisioned using carrier profiles. Granted, the provisioning
>> database in use is a little bit better than what
>> mobile-broadband-provider-info provides, so some way to manually enter
>> details would still be required in our case; however we should strive to
>> make this as rarely used as possible.
>>
>> What you suggest is a good idea, but might be overkill...
>
> Since we have to let the user make a choice on something he does not
> understand, I don't see good alternatives: currently we do the worst
> possible thing: claim that everything is ok (by accepting the APN
> settings and even showing the cellular service) and then later fail
> when connecting -- and user has absolutely no way of knowing what the
> failure was about*. I'll gladly take suggestions for simpler solutions
> that lead to a UI that isn't confusing when things go wrong.
>
If the user doesn't understand the choices he's making, then no amount
of helpful UIs will help here. Imagine you walk into a store with a
very helpful salesman, unfortunately you're speaking a different
language. If you don't have a very good idea of what you're looking
for, there's nothing he can do to help you.
My point here is that we should re-examine what we can do to make
provisioning more fool proof, rather than trying to band-aid a settings
UI that is inherently not understandable to anyone who isn't a GSM geek.
Yes, we should. As upstream project developers we have the luxury of
making statements like that (you here, I can do it in dawati-shell)
and that is definitely what actually improves the whole stack in the
long term.
Unfortunately I also have a role closer to an actual product where
"yeah, the provisioning should be better" is not an acceptable answer
to a bug report about the connectivity UI. My job is to make the UI
work as well as it can with the middleware and provisining db we have
right now. You can call it band-aiding but it's still my job.
- Jussi
8:20 a.m.
Hi Jussi,
User experience issues have more shades of grey than middleware
issues... Failing early and clearly is significantly better UX than
failing but leading the user to believe things work. I'm not "fixing"
UI has more shades of grey than a telephony stack? That is an argument
we should have over beer sometime ;)
HW problems any more than I'm "fixing" connman crashes
in my UI --
both are still events I'd rather handle (witihin limits) if that makes
the UX better.
Sure, the UI should handle the basics, e.g. connman service being
stopped by the administrator. However, going out of your way to
'handle' connman crashes or ofono HW issues is clearly the wrong thing
to do. A system service crashing is a major problem and should be
addressed by the project responsible, not by the UI.
We are in total agreement. I will gladly remove this whole UI when
you
or someone else with knowledge on this tells me that ofono + mbpi can
handle things. Likewise, if you tell me I can drop the manual settings
part and that won't harm many users, I will do it in a heart beat.
I would guesstimate that it works in 90% of the cases today, the other
5-9% are handled using a simple dialog. If this is not the case, then
we would like to know what is failing / not working.
Dropping the settings UI is probably never going to be feasible, but it
should be made into an avenue of last resort. E.g. something that the
user can be guided through by tech support at the carrier for instance.
Not something that the user should ever see under 99% of circumstances.
> My point here is that we should re-examine what we can do to
make
> provisioning more fool proof, rather than trying to band-aid a settings
> UI that is inherently not understandable to anyone who isn't a GSM geek.
Yes, we should. As upstream project developers we have the luxury of
making statements like that (you here, I can do it in dawati-shell)
and that is definitely what actually improves the whole stack in the
long term.
Please don't make this an upstream vs downstream issue. It is not.
Nobody is knocking what you're trying to do, just disagreeing on the
approach ;)
Unfortunately I also have a role closer to an actual product where
"yeah, the provisioning should be better" is not an acceptable answer
to a bug report about the connectivity UI. My job is to make the UI
work as well as it can with the middleware and provisining db we have
right now. You can call it band-aiding but it's still my job.
You are spending time optimizing the 1-5% case, clearly something is
wrong here. If provisioning isn't working properly then we should fix
it in either oFono or MBPI. And there's always the option of using
another provisioning database for the carriers being targeted for our
products...
Regards,
-Denis
10:25 a.m.
On Fri, Feb 24, 2012 at 9:20 AM, Denis Kenzior <denkenz(a)gmail.com> wrote:
> HW problems any more than I'm "fixing" connman
crashes in my UI --
> both are still events I'd rather handle (witihin limits) if that makes
> the UX better.
Sure, the UI should handle the basics, e.g. connman service being
stopped by the administrator. However, going out of your way to
'handle' connman crashes or ofono HW issues is clearly the wrong thing
to do. A system service crashing is a major problem and should be
addressed by the project responsible, not by the UI.
From a UI point of view, connman crashing and connman being stopped
are 100% same -- the only thing the UI can do is inform the user that
there is a critical problem, so they won't just wait there expecting
that Wifi AP to show up any moment now... I hope the users would never
have to see that but they sometimes do.
I'm not sure what you mean by "going out of my way". I either handle
this situation or I don't. The same goes for ofono contexts that are,
from my POV, broken.
> We are in total agreement. I will gladly remove this whole UI
when you
> or someone else with knowledge on this tells me that ofono + mbpi can
> handle things. Likewise, if you tell me I can drop the manual settings
> part and that won't harm many users, I will do it in a heart beat.
>
I would guesstimate that it works in 90% of the cases today, the other
5-9% are handled using a simple dialog. If this is not the case, then
we would like to know what is failing / not working.
Dropping the settings UI is probably never going to be feasible, but it
should be made into an avenue of last resort. E.g. something that the
user can be guided through by tech support at the carrier for instance.
Not something that the user should ever see under 99% of circumstances.
Let's work on this then -- that is my goal as well, but my
understanding of current situation was just way grimmer: maybe I've
missed some bit about how the provisioning works. This is my
understanding:
* connman shows a cellular service for every internet context
* ofono creates a internet context for every modem that is capable
* if there are multiple APNs defined in mbpi for the carrier, the
ofono context will be empy
* mbpi has lots and lots of carriers with multiple APNs, most of the
big names I checked seem to have multiple ones.
This seems to imply that by far the most common use case is this:
* user plugs in a new modem
* ofono creates an empty context (because of multiple APNs defined
for carrier)
* connman shows a broken cellular service that does absolutely
nothing -- it stays in "idle" forever and does not react to anything.
You said 90% of the cases should just work -- where does this
difference in experiences come from?
- Jussi
11:54 a.m.
Hi Jussi,
>> HW problems any more than I'm "fixing" connman
crashes in my UI --
>> both are still events I'd rather handle (witihin limits) if that makes
>> the UX better.
>
> Sure, the UI should handle the basics, e.g. connman service being
> stopped by the administrator. However, going out of your way to
> 'handle' connman crashes or ofono HW issues is clearly the wrong thing
> to do. A system service crashing is a major problem and should be
> addressed by the project responsible, not by the UI.
From a UI point of view, connman crashing and connman being stopped
are 100% same -- the only thing the UI can do is inform the user that
there is a critical problem, so they won't just wait there expecting
that Wifi AP to show up any moment now... I hope the users would never
have to see that but they sometimes do.
I would do this centralized with a system that monitors systemd status
and make sure that systemd restarts ConnMan properly. So that even if
something goes wrong, the user never really sees this. Unless it is like
a real fatal problem.
But trying to handle this different than a restart of ConnMan is kinda
weird. I would not even bother. Especially since there is nothing you
can do about it anyway.
I'm not sure what you mean by "going out of my way". I
either handle
this situation or I don't. The same goes for ofono contexts that are,
from my POV, broken.
Why are they broken again?
>> We are in total agreement. I will gladly remove this whole
UI when you
>> or someone else with knowledge on this tells me that ofono + mbpi can
>> handle things. Likewise, if you tell me I can drop the manual settings
>> part and that won't harm many users, I will do it in a heart beat.
>>
>
> I would guesstimate that it works in 90% of the cases today, the other
> 5-9% are handled using a simple dialog. If this is not the case, then
> we would like to know what is failing / not working.
>
> Dropping the settings UI is probably never going to be feasible, but it
> should be made into an avenue of last resort. E.g. something that the
> user can be guided through by tech support at the carrier for instance.
> Not something that the user should ever see under 99% of circumstances.
Let's work on this then -- that is my goal as well, but my
understanding of current situation was just way grimmer: maybe I've
missed some bit about how the provisioning works. This is my
understanding:
* connman shows a cellular service for every internet context
* ofono creates a internet context for every modem that is capable
* if there are multiple APNs defined in mbpi for the carrier, the
ofono context will be empy
* mbpi has lots and lots of carriers with multiple APNs, most of the
big names I checked seem to have multiple ones.
This seems to imply that by far the most common use case is this:
* user plugs in a new modem
* ofono creates an empty context (because of multiple APNs defined
for carrier)
* connman shows a broken cellular service that does absolutely
nothing -- it stays in "idle" forever and does not react to anything.
You said 90% of the cases should just work -- where does this
difference in experiences come from?
As pointed out by Denis, the automated setup experience can only be as
good as your database. However it is not our job to install or create
the perfect APN list. That is an OEMs job and it depends on what kind of
quality and experience they wanna have.
Problem is that MBPI needs to be clearly improved. It is currently a
dumping ground for random information. And btw. neither Apple nor
Android gets this fully right. I have an ICS that keep resetting the APN
configuration as TIM Italy while network is Wind in Canada.
So if you really care about ConnMan showing an empty cellular service,
then we can talk about adapting ConnMan to not bother showing that
service if the APN is empty.
Regards
Marcel
2:20 p.m.
On Mon, Feb 27, 2012 at 12:54 PM, Marcel Holtmann <marcel(a)holtmann.org> wrote:
> From a UI point of view, connman crashing and connman being
stopped
> are 100% same -- the only thing the UI can do is inform the user that
> there is a critical problem, so they won't just wait there expecting
> that Wifi AP to show up any moment now... I hope the users would never
> have to see that but they sometimes do.
I would do this centralized with a system that monitors systemd status
and make sure that systemd restarts ConnMan properly. So that even if
something goes wrong, the user never really sees this. Unless it is like
a real fatal problem.
But trying to handle this different than a restart of ConnMan is kinda
weird. I would not even bother. Especially since there is nothing you
can do about it anyway.
I was maybe not clear enough. I only handle the case of connman
disappearing from the bus. And by "handle" I mean "tell the user there
is a problem".
To be extra clear: I do not try to restart connman or ofono or
anything stupid like that, I totally realize that's not for my
component to do. The only thing I want to is to prevent user confusion
about what they can do or cannot do at specific times. Exactly the
same thing that I want to do when e.g. cellular services aren't
appearing as expected or when they fail.
> I'm not sure what you mean by "going out of my
way". I either handle
> this situation or I don't. The same goes for ofono contexts that are,
> from my POV, broken.
Why are they broken again?
I'm referring to the empty contexts I mentioned below. They are what I
believe most ofono+mbpi users will get at the moment, and as far as I
can tell they are useless, if not broken.
> >> We are in total agreement. I will gladly remove this
whole UI when you
> >> or someone else with knowledge on this tells me that ofono + mbpi can
> >> handle things. Likewise, if you tell me I can drop the manual settings
> >> part and that won't harm many users, I will do it in a heart beat.
> >>
> >
> > I would guesstimate that it works in 90% of the cases today, the other
> > 5-9% are handled using a simple dialog. If this is not the case, then
> > we would like to know what is failing / not working.
> >
> > Dropping the settings UI is probably never going to be feasible, but it
> > should be made into an avenue of last resort. E.g. something that the
> > user can be guided through by tech support at the carrier for instance.
> > Not something that the user should ever see under 99% of circumstances.
>
> Let's work on this then -- that is my goal as well, but my
> understanding of current situation was just way grimmer: maybe I've
> missed some bit about how the provisioning works. This is my
> understanding:
> * connman shows a cellular service for every internet context
> * ofono creates a internet context for every modem that is capable
> * if there are multiple APNs defined in mbpi for the carrier, the
> ofono context will be empy
> * mbpi has lots and lots of carriers with multiple APNs, most of the
> big names I checked seem to have multiple ones.
>
> This seems to imply that by far the most common use case is this:
> * user plugs in a new modem
> * ofono creates an empty context (because of multiple APNs defined
> for carrier)
> * connman shows a broken cellular service that does absolutely
> nothing -- it stays in "idle" forever and does not react to anything.
>
> You said 90% of the cases should just work -- where does this
> difference in experiences come from?
As pointed out by Denis, the automated setup experience can only be as
good as your database. However it is not our job to install or create
the perfect APN list. That is an OEMs job and it depends on what kind of
quality and experience they wanna have.
I understand this.
I still have to provide a UI that works with the middleware we have
and the mbpi we have.
Problem is that MBPI needs to be clearly improved. It is currently a
dumping ground for random information. And btw. neither Apple nor
Android gets this fully right. I have an ICS that keep resetting the APN
configuration as TIM Italy while network is Wind in Canada.
So if you really care about ConnMan showing an empty cellular service,
then we can talk about adapting ConnMan to not bother showing that
service if the APN is empty.
I still feel like I must be missing something: you seem to imply that
I should _not_ care about connman showing a non-working cellular
service that appears to most cellular users? I don't think that is a
real option.
If we have a way to make this work for ~95% of users -- yeah, I do
want to do that. Not showing a service for empty internet contexts
would seem to go a long way towards that goal, so I would be very
happy with that.
- Jussi
6:30 p.m.
Hi Jussi,
>> From a UI point of view, connman crashing and connman being
stopped
>> are 100% same -- the only thing the UI can do is inform the user that
>> there is a critical problem, so they won't just wait there expecting
>> that Wifi AP to show up any moment now... I hope the users would never
>> have to see that but they sometimes do.
>
> I would do this centralized with a system that monitors systemd status
> and make sure that systemd restarts ConnMan properly. So that even if
> something goes wrong, the user never really sees this. Unless it is like
> a real fatal problem.
>
> But trying to handle this different than a restart of ConnMan is kinda
> weird. I would not even bother. Especially since there is nothing you
> can do about it anyway.
I was maybe not clear enough. I only handle the case of connman
disappearing from the bus. And by "handle" I mean "tell the user there
is a problem".
I am not sure even that is a good idea. I would expect just systemd to
restart connmand right away and you could just go on with it, but fair
enough.
To be extra clear: I do not try to restart connman or ofono or
anything stupid like that, I totally realize that's not for my
component to do. The only thing I want to is to prevent user confusion
about what they can do or cannot do at specific times. Exactly the
same thing that I want to do when e.g. cellular services aren't
appearing as expected or when they fail.
>> I'm not sure what you mean by "going out of my way". I either
handle
>> this situation or I don't. The same goes for ofono contexts that are,
>> from my POV, broken.
>
> Why are they broken again?
I'm referring to the empty contexts I mentioned below. They are what I
believe most ofono+mbpi users will get at the moment, and as far as I
can tell they are useless, if not broken.
The initial context is actually there to make it a lot easier for the UI
to handle the APN setup. And checking for an empty APN is a fair thing
to do. If MBPI does not give us useful information, we are kinda
screwed.
And btw. the database/provision support in oFono is pluggable. We do not
have to use MBPI. It is just that nobody else has bothered to create
something better.
>> >> We are in total agreement. I will gladly remove
this whole UI when you
>> >> or someone else with knowledge on this tells me that ofono + mbpi can
>> >> handle things. Likewise, if you tell me I can drop the manual settings
>> >> part and that won't harm many users, I will do it in a heart beat.
>> >>
>> >
>> > I would guesstimate that it works in 90% of the cases today, the other
>> > 5-9% are handled using a simple dialog. If this is not the case, then
>> > we would like to know what is failing / not working.
>> >
>> > Dropping the settings UI is probably never going to be feasible, but it
>> > should be made into an avenue of last resort. E.g. something that the
>> > user can be guided through by tech support at the carrier for instance.
>> > Not something that the user should ever see under 99% of circumstances.
>>
>> Let's work on this then -- that is my goal as well, but my
>> understanding of current situation was just way grimmer: maybe I've
>> missed some bit about how the provisioning works. This is my
>> understanding:
>> * connman shows a cellular service for every internet context
>> * ofono creates a internet context for every modem that is capable
>> * if there are multiple APNs defined in mbpi for the carrier, the
>> ofono context will be empy
>> * mbpi has lots and lots of carriers with multiple APNs, most of the
>> big names I checked seem to have multiple ones.
>>
>> This seems to imply that by far the most common use case is this:
>> * user plugs in a new modem
>> * ofono creates an empty context (because of multiple APNs defined
>> for carrier)
>> * connman shows a broken cellular service that does absolutely
>> nothing -- it stays in "idle" forever and does not react to anything.
>>
>> You said 90% of the cases should just work -- where does this
>> difference in experiences come from?
>
> As pointed out by Denis, the automated setup experience can only be as
> good as your database. However it is not our job to install or create
> the perfect APN list. That is an OEMs job and it depends on what kind of
> quality and experience they wanna have.
I understand this.
I still have to provide a UI that works with the middleware we have
and the mbpi we have.
Maybe at this point it is time to provide something better than MBPI,
but that is out of the scope for oFono actually.
> Problem is that MBPI needs to be clearly improved. It is
currently a
> dumping ground for random information. And btw. neither Apple nor
> Android gets this fully right. I have an ICS that keep resetting the APN
> configuration as TIM Italy while network is Wind in Canada.
>
> So if you really care about ConnMan showing an empty cellular service,
> then we can talk about adapting ConnMan to not bother showing that
> service if the APN is empty.
I still feel like I must be missing something: you seem to imply that
I should _not_ care about connman showing a non-working cellular
service that appears to most cellular users? I don't think that is a
real option.
If we have a way to make this work for ~95% of users -- yeah, I do
want to do that. Not showing a service for empty internet contexts
would seem to go a long way towards that goal, so I would be very
happy with that.
As I said, we can just make ConnMan not show that service if the APN
setting from oFono is empty. Care to provide a patch for that?
Regards
Marcel
10:19 a.m.
New subject: [RFC v0] ofono: Only register network when APN is set
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
We should now show a network without an APN.
---
I have not tested this one. But something like this should do
the trick. Maybe someone with deeper knowledge on the APN
behavior could explain under which circumstances the APN is set, e.g.
see the netreg vs apn setting in this patch. Not sure if this is correct.
cheers,
daniel
plugins/ofono.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index d87d7b6..c92c3cc 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -105,6 +105,9 @@ enum ofono_api {
* the plugin about IP configuration through the updating the context's
* properties.
*
+ * The network is only registered at the core when the AccessPointName
+ * has been set.
+ *
* CDMA working flow:
*
* When a new modem appears, the plugin always powers it up. This
@@ -172,6 +175,7 @@ struct modem_data {
/* ConnectionContext Interface */
connman_bool_t active;
connman_bool_t set_active;
+ char *apn;
/* SimManager Interface */
char *imsi;
@@ -1105,6 +1109,10 @@ static int add_cm_context(struct modem_data *modem, const char
*context_path,
dbus_message_iter_get_basic(&value, &active);
DBG("%s Active %d", modem->path, active);
+ } else if (g_str_equal(key, "AccessPointName") == TRUE) {
+ dbus_message_iter_get_basic(&value, &modem->apn);
+
+ DBG("%s AccessPointName %s", modem->path, modem->apn);
}
dbus_message_iter_next(dict);
@@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection *connection,
set_connected(modem);
else
set_disconnected(modem);
+ } else if (g_str_equal(key, "AccessPointName") == TRUE) {
+ g_free(modem->apn);
+
+ dbus_message_iter_get_basic(&value, &modem->apn);
+
+ DBG("%s AccessPointName %s", modem->path, modem->apn);
+
+ if (has_interface(modem->interfaces,
+ OFONO_API_NETREG) == TRUE &&
+ modem->network != NULL) {
+ DBG("Register network at core");
+ add_network(modem);
+ }
}
return TRUE;
@@ -1518,6 +1539,9 @@ static void netreg_properties_reply(struct modem_data *modem,
return;
}
+ if (modem->apn == NULL)
+ return;
+
add_network(modem);
if (modem->active == TRUE)
@@ -2187,6 +2211,7 @@ static void remove_modem(gpointer data)
g_free(modem->serial);
g_free(modem->name);
g_free(modem->imsi);
+ g_free(modem->apn);
g_free(modem->path);
g_free(modem);
--
1.7.9.48.g85da4d
11:02 a.m.
New subject: [RFC v0] ofono: Only register network when APN is set
O> dbus_message_iter_next(dict);
@@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection
*connection,
set_connected(modem);
else
set_disconnected(modem);
+ } else if (g_str_equal(key, "AccessPointName") == TRUE) {
+ g_free(modem->apn);
+
+ dbus_message_iter_get_basic(&value, &modem->apn);
+
+ DBG("%s AccessPointName %s", modem->path, modem->apn);
+
+ if (has_interface(modem->interfaces,
+ OFONO_API_NETREG) == TRUE &&
+ modem->network != NULL) {
+ DBG("Register network at core");
+ add_network(modem);
+ }
that should be a "modem->network == NULL" of course.
3:06 p.m.
New subject: [RFC v0] ofono: Only register network when APN is set
On Tue, Feb 28, 2012 at 11:19 AM, Daniel Wagner <wagi(a)monom.org> wrote:
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
We should now show a network without an APN.
---
I have not tested this one. But something like this should do
the trick. Maybe someone with deeper knowledge on the APN
behavior could explain under which circumstances the APN is set, e.g.
see the netreg vs apn setting in this patch. Not sure if this is correct.
cheers,
daniel
Thanks Daniel. This sort of works after some fixes but it looks like
there are still issues if modem or context properties change. I'll
have a go a fixing it later today. I'm including my initial comments
below for reference (just in case I don't manage to fix them).
Also while I remember: cm_context_added() does a lookup on modem_hash
when it probably shoud use context_hash. I'll include this in the
patches.
plugins/ofono.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index d87d7b6..c92c3cc 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -105,6 +105,9 @@ enum ofono_api {
* the plugin about IP configuration through the updating the context's
* properties.
*
+ * The network is only registered at the core when the AccessPointName
+ * has been set.
+ *
* CDMA working flow:
*
* When a new modem appears, the plugin always powers it up. This
@@ -172,6 +175,7 @@ struct modem_data {
/* ConnectionContext Interface */
connman_bool_t active;
connman_bool_t set_active;
+ char *apn;
probably makes sense to have this in network_context -- easier to keep
them in sync if e.g. context disappears.
/* SimManager Interface */
char *imsi;
@@ -1105,6 +1109,10 @@ static int add_cm_context(struct modem_data *modem, const char
*context_path,
dbus_message_iter_get_basic(&value, &active);
DBG("%s Active %d", modem->path, active);
+ } else if (g_str_equal(key, "AccessPointName") == TRUE) {
+ dbus_message_iter_get_basic(&value, &modem->apn);
copying needed.
+
+ DBG("%s AccessPointName %s", modem->path,
modem->apn);
}
dbus_message_iter_next(dict);
@@ -1180,6 +1188,19 @@ static gboolean context_changed(DBusConnection *connection,
set_connected(modem);
else
set_disconnected(modem);
+ } else if (g_str_equal(key, "AccessPointName") == TRUE) {
+ g_free(modem->apn);
+
+ dbus_message_iter_get_basic(&value, &modem->apn);
+
+ DBG("%s AccessPointName %s", modem->path, modem->apn);
copy needed as well
+
+ if (has_interface(modem->interfaces,
+ OFONO_API_NETREG) == TRUE &&
+ modem->network != NULL) {
+ DBG("Register network at core");
+ add_network(modem);
+ }
* if a network exists and apn is empty -> remove_network()
* if a network does not exist and netreg iface is supported and apn
is not empty -> add_network()
also, probably need to call set_connected() if Active is set?
}
return TRUE;
@@ -1518,6 +1539,9 @@ static void netreg_properties_reply(struct modem_data *modem,
return;
}
+ if (modem->apn == NULL)
+ return;
+
This doesn't actually work as the 'empty' apn is "". Now that I
think
about it, it would be safer and easier to just save a boolean
apn_is_valid...
add_network(modem);
if (modem->active == TRUE)
@@ -2187,6 +2211,7 @@ static void remove_modem(gpointer data)
g_free(modem->serial);
g_free(modem->name);
g_free(modem->imsi);
+ g_free(modem->apn);
g_free(modem->path);
g_free(modem);
--
1.7.9.48.g85da4d
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
5:33 p.m.
New subject: [RFC v0] ofono: Only register network when APN is set
Hi guys,
> We should now show a network without an APN.
> ---
> I have not tested this one. But something like this should do
> the trick. Maybe someone with deeper knowledge on the APN
> behavior could explain under which circumstances the APN is set, e.g.
> see the netreg vs apn setting in this patch. Not sure if this is correct.
>
> cheers,
> daniel
Thanks Daniel. This sort of works after some fixes but it looks like
there are still issues if modem or context properties change. I'll
have a go a fixing it later today. I'm including my initial comments
below for reference (just in case I don't manage to fix them).
can you please move this to the ConnMan mailing list.
Regards
Marcel
3199
days inactive
3206
days old
15 comments
4 participants
participants (4)
-
Daniel Wagner -
Denis Kenzior -
Jussi Kukkonen -
Marcel Holtmann