Re: [RFC v0] ofono: Only register network when APN is set
On Tue, Feb 28, 2012 at 11:19 AM, Daniel Wagner w...@monom.org wrote:
From: Daniel Wagner daniel.wag...@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@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: trying to understand context creation
On Fri, Feb 24, 2012 at 9:20 AM, Denis Kenzior denk...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: trying to understand context creation
On Mon, Feb 27, 2012 at 12:54 PM, Marcel Holtmann mar...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: trying to understand context creation
Hi Dennis, On Wed, Feb 22, 2012 at 11:19 AM, Denis Kenzior denk...@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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: trying to understand context creation
On Fri, Feb 24, 2012 at 7:12 AM, Denis Kenzior denk...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: trying to understand context creation
On Tue, Feb 21, 2012 at 4:03 PM, Denis Kenzior denk...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
trying to understand context creation
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: crash when unplugged modem when it was still initializing
On Tue, Jan 24, 2012 at 7:35 PM, Denis Kenzior denk...@gmail.com wrote: On 01/24/2012 03:33 PM, Jussi Kukkonen wrote: On Tue, Jan 24, 2012 at 11:19 PM, Jussi Kukkonen jussi.kukko...@intel.com wrote: Hi, I happened to unplug my dongle quite soon after starting ofono. It promptly aborted. and it just happened again with no relation to unplugging devices or starting ofonod so those were red herrings. In fact I hadn't touched anything for a moment: connmand and ofonod were both running. Try the following patch. Unfortunately today I have not been able to reproduce this, even without the patch. I bet the problem was exposed by the constant usb device appearance/disappearance that I described in the other thread, it really exercised ofono/connman (found four different segfaults...). Now that I've figured out a way to keep that from happening I haven't seen this problem again (it seems the dongle magically starts working when I connect it using a USB hub in the laptop dock -- this explains why I would only see the problem when working from home). I'll try leaving the modem connected via the laptop USB ports to 'stress test' when I can, but I have my own bugs that I can only work on if I have a working modem, ofono and connman ... so reproducing this might not happen right away.. - Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: crash when unplugged modem when it was still initializing
On Tue, Jan 24, 2012 at 7:35 PM, Denis Kenzior denk...@gmail.com wrote: On 01/24/2012 03:33 PM, Jussi Kukkonen wrote: On Tue, Jan 24, 2012 at 11:19 PM, Jussi Kukkonen jussi.kukko...@intel.com wrote: Hi, I happened to unplug my dongle quite soon after starting ofono. It promptly aborted. and it just happened again with no relation to unplugging devices or starting ofonod s othose were red herrings. In fact I hadn't touched anything for a moment: connmand and ofonod were both running. Try the following patch. Actually I just figured out a way to reproduce this pretty consistently: * plug in modem, wait until it settles * kill ofonod if running, restart it, wait until it settles (mine is waiting for a pin entry) * unplug modem I confirm that it's hitting sim_spn_close() before spn stuff is initialized, and that your patch prevents the crash. - Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
crash when unplugged modem when it was still initializing
Hi, I happened to unplug my dongle quite soon after starting ofono. It promptly aborted. This is with git master from today. - Jussi $ sudo src/ofonod -n -d ofonod[16006]: oFono version 1.3 ofonod[16006]: src/plugin.c:__ofono_plugin_init() ofonod[16006]: plugins/push-notification.c:push_notification_init() ofonod[16006]: plugins/smart-messaging.c:smart_messaging_init() ofonod[16006]: examples/emulator.c:example_emulator_init() ofonod[16006]: src/gprs-provision.c:ofono_gprs_provision_driver_register() driver: 0x81765c0 name: Example GPRS context provisioning ofonod[16006]: src/nettime.c:ofono_nettime_driver_register() driver: 0x8176580 name: Example Network Time ofonod[16006]: src/history.c:ofono_history_driver_register() driver: 0x8176540 name: Example Call History ofonod[16006]: src/cdma-provision.c:ofono_cdma_provision_driver_register() driver: 0x8176500 name: CDMA provisioning ofonod[16006]: src/gprs-provision.c:ofono_gprs_provision_driver_register() driver: 0x81764c0 name: Provisioning ofonod[16006]: plugins/connman.c:connman_init() ofonod[16006]: src/private-network.c:ofono_private_network_driver_register() driver: 0x8176480, name: ConnMan Private Network ofonod[16006]: plugins/dun_gw.c:dun_gw_init() ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176380, name: hfp ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176320, name: sap ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81762a0, name: telit ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176200, name: sim900 ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81761a0, name: samsung ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176140, name: speedupcdma ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81760e0, name: speedup ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176080, name: alcatel ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8176020, name: linktop ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175fc0, name: nokiacdma ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175f60, name: nokia ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175f00, name: tc65 ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175e60, name: ste ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175e00, name: ifx ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175da0, name: palmpre ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175d40, name: novatel ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175ce0, name: sierra ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175c60, name: huawei ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175c00, name: zte ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175ba0, name: hso ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175b40, name: mbm ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175ae0, name: calypso ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175a80, name: wavecom ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x8175a20, name: gobi ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81759c0, name: g1 ofonod[16006]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() driver: 0x8175940, name: cdmamodem ofonod[16006]: src/modem.c:ofono_devinfo_driver_register() driver: 0x8175960, name: cdmamodem ofonod[16006]: src/cdma-connman.c:ofono_cdma_connman_driver_register() driver: 0x8175984, name: cdmamodem ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81758a0, name: phonesim ofonod[16006]: src/modem.c:ofono_modem_driver_register() driver: 0x81758e0, name: localhfp ofonod[16006]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x8175874, name: phonesim ofonod[16006]: src/ctm.c:ofono_ctm_driver_register() driver: 0x8175860, name: phonesim ofonod[16006]: plugins/phonesim.c:parse_config() filename /etc/ofono/phonesim.conf ofonod[16006]: Reading of /etc/ofono/phonesim.conf failed: No such file or directory ofonod[16006]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x8175740, name: hfpmodem ofonod[16006]: src/modem.c:ofono_devinfo_driver_register() driver: 0x81757fc, name: hfpmodem ofonod[16006]: src/network.c:ofono_netreg_driver_register() driver: 0x81757a0, name: hfpmodem ofonod[16006]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x81757d4, name: hfpmodem ofonod[16006]: src/handsfree.c:ofono_handsfree_driver_register() driver: 0x8175818, name: hfpmodem ofonod[16006]: src/network.c:ofono_netreg_driver_register() driver: 0x81756c0, name: dunmodem ofonod[16006]: src/gprs.c:ofono_gprs_driver_register() driver: 0x81756ec, name: dunmodem ofonod[16006]:
Re: crash when unplugged modem when it was still initializing
On Tue, Jan 24, 2012 at 11:19 PM, Jussi Kukkonen jussi.kukko...@intel.com wrote: Hi, I happened to unplug my dongle quite soon after starting ofono. It promptly aborted. and it just happened again with no relation to unplugging devices or starting ofonod s othose were red herrings. In fact I hadn't touched anything for a moment: connmand and ofonod were both running. - Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: create_modem/destroy_modem() loop with Huawei USB modem
On Wed, Jan 4, 2012 at 2:30 PM, Jussi Kukkonen jussi.kukko...@intel.com wrote: I'm sometimes seeing a create_modem/destroy_modem() loop that seems to go on forever: Maybe half an hour ago I inserted a USB modem and tried to test/enable-modem (although I think enable-modem is not needed to trigger it). Now the Modem objects keep appearing and disappearing on the system bus: It's currently at /huawei189 and counting. The device is a Huawei E1550, connected straight to a laptop USB port. This has happened maybe five times altogether but it's not easily reproducable. I have my own ofono client running but it doesn't really do anything other than attach to Manager and Modem signals (and do the corresponding initial GetModems()/GetProperties() method calls). This has just started happening a lot (as in 100% for last 20 minutes) for an unknown reason -- this stress test was possibly how I found the crash I reported a few minutes ago... anyway, to be able to test other bugs I had to investigate this further: turns out this is probably not a ofono problem, but I would appreciate any help from this list. I'm seeing this happen constantly, over and over, even if ofonod is not running (as long as I've run it once to do the modeswitch) : Jan 25 00:13:28 loki kernel: [ 560.421045] usb 1-1.1: reset high-speed USB device number 66 using ehci_hcd Jan 25 00:13:28 loki kernel: [ 560.518464] option 1-1.1:1.3: GSM modem (1-port) converter detected Jan 25 00:13:28 loki kernel: [ 560.518619] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0 Jan 25 00:13:28 loki kernel: [ 560.518769] option 1-1.1:1.2: GSM modem (1-port) converter detected Jan 25 00:13:28 loki kernel: [ 560.519447] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB1 Jan 25 00:13:28 loki kernel: [ 560.520149] option 1-1.1:1.1: GSM modem (1-port) converter detected Jan 25 00:13:28 loki kernel: [ 560.520321] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB2 Jan 25 00:13:28 loki kernel: [ 560.520440] option 1-1.1:1.0: GSM modem (1-port) converter detected Jan 25 00:13:28 loki kernel: [ 560.520584] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB3 Jan 25 00:13:28 loki kernel: [ 560.542530] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3 Jan 25 00:13:28 loki kernel: [ 560.542548] option 1-1.1:1.0: device disconnected Jan 25 00:13:28 loki kernel: [ 560.542766] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2 Jan 25 00:13:28 loki kernel: [ 560.542783] option 1-1.1:1.1: device disconnected Jan 25 00:13:28 loki kernel: [ 560.543132] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 Jan 25 00:13:28 loki kernel: [ 560.543149] option 1-1.1:1.2: device disconnected Jan 25 00:13:28 loki kernel: [ 560.543204] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 Jan 25 00:13:28 loki kernel: [ 560.543219] option 1-1.1:1.3: device disconnected Any hints to what this might and and how I can avoid it are welcome. - Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: api property notification order
Hi, thanks for a comprehensive answer. On Mon, Jan 2, 2012 at 2:14 AM, Denis Kenzior denk...@gmail.com wrote: [...clip...] returns. From an API user point of view that is wrong. As an example I thought this would be a fairly logical way to handle PIN resets: * property change SimManager.PinRequired=puk - show pin reset UI to user * user enters PUK and new PIN - call SimManager.PinReset() * wait for method to return, present any errors. In particular org.ofono.Error.Failed: It looks like you entered the wrong PUK. You can try again X more times before the SIM is permanently locked Doing that will mislead the user really badly as the Retries-property hasn't been decreased yet... Ah, but the problem here is really not the ordering. The problem is that this is a fairly complicated transaction, requiring several calls to the driver and affecting several attributes at once. Not only do the pin retries have to be checked, but also what the new PIN required is or whether the SIM is blocked forever. e.g. you might actually have run out of PUK retries and blocked your SIM forever. To add additional complexity, not all modem drivers support querying pin retries, or we simply do not have the AT command details available... What is happening here is that the method return is generated purely on the success / failure of the pin reset operation, not Ah, I see. I did take a look at the code but missed this. I was afraid you might have reasons for it... From a software 'completeness' POV I should just make my UI messages change as the situation in ofono changes, but I dislike that for two reasons: First, it makes the whole thing a lot more complex, and second, changing UI messages is just bad design: I'd rather wait until the 'side effects' like retry-counts are all there and then show the message. I realise I can never be 100% sure that things won't change but I'm mostly interested in the 99.9% cases. It looks like I don't really have an alternative though -- I think I'll delay the message creation by a very short time so the retry count is correct in most cases and add state handling for the message content to cover the 0.x%. In general I'm open to the idea of querying pin retries and pin type before returning from PIN/PUK related method calls. However, this probably needs to be studied a bit more carefully for feasibility and impact. That sounds good to me. Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
api property notification order
Hi, I'm wondering if there could be some additional promises made by the API about the order of certain property changes and method call returns. I realize what I'm talking about is fairly close to an API change so it's more like a discussion starter than a ready suggestion. The exact problem I ran into is that property changes that are a result of a API method call are notified _after_ the method call returns. From an API user point of view that is wrong. As an example I thought this would be a fairly logical way to handle PIN resets: * property change SimManager.PinRequired=puk - show pin reset UI to user * user enters PUK and new PIN - call SimManager.PinReset() * wait for method to return, present any errors. In particular org.ofono.Error.Failed: It looks like you entered the wrong PUK. You can try again X more times before the SIM is permanently locked Doing that will mislead the user really badly as the Retries-property hasn't been decreased yet... From my point of view the order of events should be: 1. properties that are less likely to trigger UI actions themselves (e.g. Retries, ServiceNumbers) 2. properties that can be expected to trigger UI actions themselves (e.g. PinRequired) 3. method call returns The distinction between 1 and 2 is sugar coating but unless method calls return after property changes, UI development will be more complex than I thought. Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] sim: fix typo: network is matching pin type for networkpuk
--- At least this looks like a typo -- can't say I know anything about the stranger pin types though... src/sim.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/sim.c b/src/sim.c index 4412db8..ceead1e 100644 --- a/src/sim.c +++ b/src/sim.c @@ -194,7 +194,7 @@ static enum ofono_sim_password_type puk2pin(enum ofono_sim_password_type type) case OFONO_SIM_PASSWORD_SIM_PUK2: return OFONO_SIM_PASSWORD_SIM_PIN2; case OFONO_SIM_PASSWORD_PHNET_PUK: - return OFONO_SIM_PASSWORD_PHNET_PUK; + return OFONO_SIM_PASSWORD_PHNET_PIN; case OFONO_SIM_PASSWORD_PHNETSUB_PUK: return OFONO_SIM_PASSWORD_PHNETSUB_PIN; case OFONO_SIM_PASSWORD_PHSP_PUK: -- 1.7.7.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Getting Modem properties using qt dbus programming -reg
On 05/27/2010 03:35 PM, krishna k wrote: Hi, I am trying to implement application using qt dbus module, Which will call SetProperty with parameters QString, QVariant. ... I am trying the same thing using qt program... QDBusConnection bus = QDBusConnection::systemBus(); QDBusInterface dbus_iface(org.ofono, /phonesim0/operator/23402, org.ofono.Modem, bus); bool value = true; dbus_iface.call(SetProperty, QString(Powered), QVariant(QVariant::Bool,value)); I believe v maps to QDBusVariant, not QVariant. Maybe something like this works: bool value = true; var = QDBusVariant (QVariant(QVariant::Bool,value)); dbus_iface.call(SetProperty, QString(Powered), var); Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: RFC: API for Neighbouring Cell Info
Hi, First, as a general comment: if this sort of info was available, I'd definitely use it (see http://github.com/jku/geoclue/commits/new-stuff for a first version using currently available API). Neighbor cell info would make non-complete cell location databases so much more useful... Aki Niemi wrote: pe, 2010-01-29 kello 16:56 +0100, ext Denis Kenzior kirjoitti: Honestly I don't like either approach, the Agent pattern would be a much better fit here. This would allow us to specify the polling/update interval and stop neighbor cell updates when no one is interested in them. In my experience, the positioning guys don't need periodic updates at all. The data needs to be fetched on demand. Like whenever the user starts up a location-aware application. I'm willing to bet this is a chicken-egg problem: Why design software that uses periodic location updates if they aren't available? Only exposing plain polling is fine if it makes sense in a powersaving (and api simplicity) sense: a version of periodic updating can always be implemented at the position service (geoclue) level if it seems useful. - Jussi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
