* trying to understand context creation @ 2012-02-21 15:20 Jussi Kukkonen 2012-02-21 14:03 ` Denis Kenzior 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-21 15:20 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2779 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-21 15:20 trying to understand context creation Jussi Kukkonen @ 2012-02-21 14:03 ` Denis Kenzior 2012-02-22 9:58 ` Jussi Kukkonen 0 siblings, 1 reply; 16+ messages in thread From: Denis Kenzior @ 2012-02-21 14:03 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 5148 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-21 14:03 ` Denis Kenzior @ 2012-02-22 9:58 ` Jussi Kukkonen 2012-02-22 9:19 ` Denis Kenzior 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-22 9:58 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2577 bytes --] On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior <denkenz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-22 9:58 ` Jussi Kukkonen @ 2012-02-22 9:19 ` Denis Kenzior 2012-02-24 11:55 ` Jussi Kukkonen 0 siblings, 1 reply; 16+ messages in thread From: Denis Kenzior @ 2012-02-22 9:19 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 3317 bytes --] Hi Jussi, On 02/22/2012 03:58 AM, Jussi Kukkonen wrote: > On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior <denkenz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-22 9:19 ` Denis Kenzior @ 2012-02-24 11:55 ` Jussi Kukkonen 2012-02-24 5:12 ` Denis Kenzior 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-24 11:55 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2290 bytes --] Hi Dennis, On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior <denkenz@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". ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-24 11:55 ` Jussi Kukkonen @ 2012-02-24 5:12 ` Denis Kenzior 2012-02-24 16:13 ` Jussi Kukkonen 0 siblings, 1 reply; 16+ messages in thread From: Denis Kenzior @ 2012-02-24 5:12 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 3305 bytes --] 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@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-24 5:12 ` Denis Kenzior @ 2012-02-24 16:13 ` Jussi Kukkonen 2012-02-24 7:20 ` Denis Kenzior 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-24 16:13 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 3650 bytes --] On Fri, Feb 24, 2012 at 7:12 AM, Denis Kenzior <denkenz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-24 16:13 ` Jussi Kukkonen @ 2012-02-24 7:20 ` Denis Kenzior 2012-02-27 9:25 ` Jussi Kukkonen 0 siblings, 1 reply; 16+ messages in thread From: Denis Kenzior @ 2012-02-24 7:20 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2911 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-24 7:20 ` Denis Kenzior @ 2012-02-27 9:25 ` Jussi Kukkonen 2012-02-27 10:54 ` Marcel Holtmann 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-27 9:25 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2885 bytes --] On Fri, Feb 24, 2012 at 9:20 AM, Denis Kenzior <denkenz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-27 9:25 ` Jussi Kukkonen @ 2012-02-27 10:54 ` Marcel Holtmann 2012-02-27 13:20 ` Jussi Kukkonen 0 siblings, 1 reply; 16+ messages in thread From: Marcel Holtmann @ 2012-02-27 10:54 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 4085 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-27 10:54 ` Marcel Holtmann @ 2012-02-27 13:20 ` Jussi Kukkonen 2012-02-27 17:30 ` Marcel Holtmann 0 siblings, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-27 13:20 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 4987 bytes --] On Mon, Feb 27, 2012 at 12:54 PM, Marcel Holtmann <marcel@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: trying to understand context creation 2012-02-27 13:20 ` Jussi Kukkonen @ 2012-02-27 17:30 ` Marcel Holtmann 2012-02-28 9:19 ` [RFC v0] ofono: Only register network when APN is set Daniel Wagner 0 siblings, 1 reply; 16+ messages in thread From: Marcel Holtmann @ 2012-02-27 17:30 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 5920 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC v0] ofono: Only register network when APN is set 2012-02-27 17:30 ` Marcel Holtmann @ 2012-02-28 9:19 ` Daniel Wagner 2012-02-28 10:02 ` Daniel Wagner 2012-02-28 14:06 ` Jussi Kukkonen 0 siblings, 2 replies; 16+ messages in thread From: Daniel Wagner @ 2012-02-28 9:19 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 2564 bytes --] From: Daniel Wagner <daniel.wagner@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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [RFC v0] ofono: Only register network when APN is set 2012-02-28 9:19 ` [RFC v0] ofono: Only register network when APN is set Daniel Wagner @ 2012-02-28 10:02 ` Daniel Wagner 2012-02-28 14:06 ` Jussi Kukkonen 1 sibling, 0 replies; 16+ messages in thread From: Daniel Wagner @ 2012-02-28 10:02 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 662 bytes --] 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC v0] ofono: Only register network when APN is set 2012-02-28 9:19 ` [RFC v0] ofono: Only register network when APN is set Daniel Wagner 2012-02-28 10:02 ` Daniel Wagner @ 2012-02-28 14:06 ` Jussi Kukkonen 2012-02-28 16:33 ` Marcel Holtmann 1 sibling, 1 reply; 16+ messages in thread From: Jussi Kukkonen @ 2012-02-28 14:06 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 4639 bytes --] On Tue, Feb 28, 2012 at 11:19 AM, Daniel Wagner <wagi@monom.org> wrote: > From: Daniel Wagner <daniel.wagner@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC v0] ofono: Only register network when APN is set 2012-02-28 14:06 ` Jussi Kukkonen @ 2012-02-28 16:33 ` Marcel Holtmann 0 siblings, 0 replies; 16+ messages in thread From: Marcel Holtmann @ 2012-02-28 16:33 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 751 bytes --] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-02-28 16:33 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-21 15:20 trying to understand context creation Jussi Kukkonen 2012-02-21 14:03 ` Denis Kenzior 2012-02-22 9:58 ` Jussi Kukkonen 2012-02-22 9:19 ` Denis Kenzior 2012-02-24 11:55 ` Jussi Kukkonen 2012-02-24 5:12 ` Denis Kenzior 2012-02-24 16:13 ` Jussi Kukkonen 2012-02-24 7:20 ` Denis Kenzior 2012-02-27 9:25 ` Jussi Kukkonen 2012-02-27 10:54 ` Marcel Holtmann 2012-02-27 13:20 ` Jussi Kukkonen 2012-02-27 17:30 ` Marcel Holtmann 2012-02-28 9:19 ` [RFC v0] ofono: Only register network when APN is set Daniel Wagner 2012-02-28 10:02 ` Daniel Wagner 2012-02-28 14:06 ` Jussi Kukkonen 2012-02-28 16:33 ` Marcel Holtmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.