**** BEGIN LOGGING AT Thu Apr 21 02:59:58 2011 Apr 21 05:15:47 denkenz: thanks, will look it up in bugzilla Apr 21 05:17:22 it was a null pointer dereference in gprs_context_remove (gc->atom was NULL) Apr 21 05:17:57 called from mbm_disconnect, but i can't reproduce it Apr 21 05:19:06 this happens when a ppp context is active and forcefully deactivated by e.g. CFUN Apr 21 05:19:43 The disconnect function gets called, which tries to unref the context, but it is already gone due to online->offline transition Apr 21 05:21:54 there are a couple of ways to fix this, either move gprs + gprs context to post_sim, or null out the gprs/gprs context when going offline, making sure that the disconnect function does not trigger a remove Apr 21 05:23:00 Martin diagnosed this ages ago, but only fixed it for Huawei Apr 21 05:25:02 Easiest and most elegant fix is to just move this stuff to post_sim Apr 21 05:25:20 i can't make sense out of the code.. mbm.c creates two contexts but frees only one of them Apr 21 05:26:20 Ah, you're missing the magic cause Apr 21 05:26:36 So all these vendors decided that sending a NO CARRIER isn't enough Apr 21 05:26:51 So they do that, and then physically hang up the tty Apr 21 05:27:04 But this is only needed for ppp contexts Apr 21 05:27:16 MBM creates 2 contexts indeed, but only the second one is ppp Apr 21 05:27:41 ooh Apr 21 05:28:35 hence why we set mbm_disconnect only on the data port (e.g. ppp) Apr 21 05:29:07 And yes, mixing and matching high speed and ppp contexts is freaking cool ;) Apr 21 05:33:08 ;) Apr 21 05:33:36 so i guess they couldn't be both high speed Apr 21 05:35:10 nope, doesn't seem to work Apr 21 05:36:01 and only 1 eth interface is created by mbm anyway Apr 21 05:36:10 Maybe they will do this properly in later versions Apr 21 05:44:59 it looks like it would be enough to watch the modem state in mbm.c and null out data->gc when going offline Apr 21 07:03:16 Hi, is there way to disable GSM support on ofono? I need to maintain 3G connection even in case of low bandwidth, but the operator is trying to force connection to GSM Apr 21 15:28:07 denkenz: ping Apr 21 15:28:17 fdalleau: pong Apr 21 15:29:39 hi, i've sent a patch for +CLCC, next one i've agreed with fdanis to work on is about +CHLD Apr 21 15:30:48 for HFP iirc, only CHLD= 1 and 2 are mandatory Apr 21 15:31:36 is that enough for you, or do you want other values ? Apr 21 15:32:28 CHLD=1 and 2 are only mandatory if 3way call is supported Apr 21 15:32:47 it is fine to start with just mandatory ones, but I want all of them Apr 21 15:33:41 ok Apr 21 15:35:02 next question ! the drivers have one entry point for almost each CHLD values, 0:release_all_held, 1:release_all_active, 2:hold_all_active, 3:create_multiparty Apr 21 15:35:39 do you need fallback mechanism if the entry point is not implemented? (similar to what is done for CHUP) Apr 21 15:39:10 I mean for example release_all _active could be implemented with release_specific Apr 21 15:41:18 following what oFono does already is what I would recommend Apr 21 15:41:32 There are slight variations between vendors Apr 21 15:42:03 However, I'd stick to calling the corresponding driver functions when possible Apr 21 15:42:16 release_specific should probably not be abused too much Apr 21 15:44:37 Just take a stab at it, feel free to start simple Apr 21 15:44:48 ok that is my opinion too, but I just wanted to make sure Apr 21 15:46:00 if the driver function is not available, do you agree about returning an error? Apr 21 15:53:29 i guess it's yes, i'll send the patch and i'll see your comment ;) Apr 21 16:54:49 denkenz: ping Apr 21 18:19:16 I need to know how long it takes until the modem or ofono times out for an incoming call. Essentially how long we have to play a ringtone. I need this to make sure that our digital rights management interfaces don't choke our ability to play a rights protected file so that on failure to play a file we have enough time to play a default ringtone before the call goes to voicemail. I'm guessing that service providers also affect this timeout bu Apr 21 18:19:32 I'm not* sure ^ Apr 21 18:21:55 fdanis: pong Apr 21 18:22:31 mnementh: Nobody can tell you, this depends on the call forwarding on no reply setting Apr 21 18:22:59 the ring timer can be anywhere from 1 to 30 seconds Apr 21 18:27:18 The typical default setting on most networks is 20 seconds Apr 21 19:39:20 denkenz: thanks for the reply. Is the call forwarding and no reply setting set by the carriers? Apr 21 19:40:06 no, it is set by the user with the network, the network provides a default Apr 21 19:41:34 The bottom line is that you need to have a ringtone going ~300 ms after you detect an incoming call Apr 21 19:41:41 If you don't, then users get pissed off Apr 21 19:42:37 denkenz: thanks I will forward information on **** ENDING LOGGING AT Fri Apr 22 02:59:57 2011