**** BEGIN LOGGING AT Mon Sep 20 02:59:57 2010 Sep 20 11:21:56 anyone know why usb_modeswitch is so slow? any way to make it faster? Sep 20 12:07:37 oh god I hate huawei... Sep 20 12:27:18 sim state stays in invlid_or_locked? does wih with disabled pin work? Sep 20 12:29:21 I'll send v2 in few minutes. I have now pin unlocked case working now Sep 20 14:38:26 kvalo: hi! I'm having problems applying the "huawei: fix online logic" patches. is it supposed to be applied against the latest git code? Sep 20 14:39:54 thiago_syst: hello. yes, the two patches should apply to current git Sep 20 14:40:27 thiago_syst: what problems you have? Sep 20 14:41:43 don't know what I'm doing wrong, but I'm getting "7 out of 7 hunks FAILED" :) Sep 20 14:43:16 heh :) Sep 20 14:43:42 patch -p1 < foo.patch? Sep 20 14:44:01 yes, that's what I'm doing Sep 20 14:44:18 git status? Sep 20 14:44:53 and 'git log | head -5' Sep 20 14:46:09 commit 9f906504a572c08a8767380ca4d0511af757e798 Sep 20 14:46:24 atmodem: Allow setting PPP debug via environment variable Sep 20 14:46:38 it's a clean tree, just cloned it Sep 20 14:48:29 I suspect my patch file is damaged Sep 20 14:48:32 kvalo: what's the reason for this Sep 20 14:48:34 @@ -610,6 +647,9 @@ static void huawei_pre_sim(struct ofono_modem *modem) Sep 20 14:48:34 if (data->voice == TRUE) Sep 20 14:48:35 ofono_voicecall_create(modem, OFONO_VENDOR_HUAWEI, Sep 20 14:48:35 "atmodem", data->pcui); Sep 20 14:48:35 + Sep 20 14:48:35 + data->sim_poll_count = 0; Sep 20 14:48:36 + query_sim_state(modem); Sep 20 14:49:19 thiago_syst: I suspect too. give a me few mins, I'll upload a tarball for you. Sep 20 14:50:20 denkenz: in case SIMST event is not received. my modem seems to send it, but I doubt if all modems does that Sep 20 14:50:42 Yeah, but you already start a poll on enable Sep 20 14:51:11 denkenz: but that will stop when sim_state goes to 0 Sep 20 14:51:47 err? Sep 20 14:53:24 I'm lost, but btw, you should reset sim_poll count to 0 either on enable or disable Sep 20 14:53:45 Otherwise power up / down in random timing order can mess your detection code Sep 20 14:55:51 thiago_syst: http://www.valot.fi/kalle/tmp/ofono/patches-huawei-cold-start-v2.tar.gz Sep 20 14:56:21 denkenz: need to go now, I'll answer you later Sep 20 14:59:57 kvalo: tks, will give it a try Sep 20 15:04:13 it applied ok :) I'll test with my huawei modem and post the results. tks Sep 20 15:04:13 denkenz: need more information on this SMS storage Sep 20 15:05:52 lol Sep 20 15:06:26 go ahead Sep 20 15:11:23 I accept that the SMS is routed directly to ofono. What I'm concerned is, if there is an message application or something like that which gets this incoming SMS and stores it in the sms storage Sep 20 15:11:23 ok, in another way where is the incoming SMS stored? Sep 20 15:11:59 is it now spooled until there the complete message is received, and then signaled? Sep 20 15:12:43 btw, can you explicitly tell me that hey, we now have memory, please send more SMSs with AT commands? Sep 20 15:13:27 in N900, we had to explicitly ack the message in order to remove it from spool Sep 20 15:21:37 I dont know AT command to explicitly inform the network that we now have memory. Sep 20 15:24:54 denkenz: back now Sep 20 15:25:11 Jeevaka: It is assumed that SMSes are never lost Sep 20 15:25:11 but, if we send a status report for the incoming message as memory full, then network will not deliver any messages to the Mobile until it is explicitly informed of the memory availability Sep 20 15:25:19 On today's devices, we have gigabytes of store Sep 20 15:25:44 If a 160 byte message gets lost, you have other issues Sep 20 15:25:59 pessi: There is no way, until you ack the message Sep 20 15:26:49 denkenz: the timer is stopped after sim_state goes to 0. and it's started again in pre_sim(). I wanted to separate the two phases Sep 20 15:26:49 what if there is a device which allocates fixed size for a SMS store? Sep 20 15:27:23 Jeevaka: Then the SMS store needs to be round-robined and remove the older entries Sep 20 15:27:56 oFono does now allow for sim full conditions, as that is something from 1990s, not 2010s Sep 20 15:28:06 Welcome to 21st century Sep 20 15:28:49 kvalo: I still don't get it, pre_sim gets called right after ofono_inserted_notify(TRUE) Sep 20 15:28:54 Why bother? Sep 20 15:32:10 denkenz: I can change it if you want. I don't care :) Sep 20 15:33:12 I just want to understand whether this is a real need, or just some extraneous thing Sep 20 15:33:33 Once you notify of sim insertion, the polling does nothing Sep 20 15:33:57 I think with huawei we never know what is really needed until people test it Sep 20 15:34:18 Yeah, but the issue here is: Sep 20 15:34:36 set_powered(TRUE) ---> driver Sep 20 15:34:40 driver returns -> pre_sim Sep 20 15:35:11 so you're starting a poll in enable(), then cancel it and re-start it again Sep 20 15:37:43 technically I don't cancel, I just don't rerun it. but as I said, I can change it so that it polls until sim is ready. Sep 20 15:38:53 I just want to get huawei working again Sep 20 15:40:40 I know, but this doesn't seem right Sep 20 15:42:16 + case HUAWEI_SIM_STATE_INVALID_OR_LOCKED: Sep 20 15:42:17 + ofono_modem_set_powered(modem, TRUE); Sep 20 15:42:17 + Sep 20 15:42:17 + return FALSE; Sep 20 15:42:33 This is also a bad idea, we should send CFUN=5 here as well Sep 20 15:42:54 Otherwise in PIN entry case we're stuck with a powered modem, potentially for a long time, wasting battery Sep 20 15:45:35 Man, but Huawei firmware sucks Sep 20 15:46:50 Can you play with sending a CPIN? when cold starting Sep 20 15:46:51 See plugins/mbm.c for details Sep 20 15:47:02 I'm now thinking we need to skip using SIMST / SYSINFO completely Sep 20 15:49:01 I'm running out of my time quota for this... Sep 20 15:49:20 I can try that approach, but don't know when Sep 20 15:51:00 denkenz: if you nack the message (because memory full, you will never get a chance to ack Sep 20 15:51:22 pessi: Sure, but we never do that Sep 20 15:51:46 pessi: The only possible case where we might need to nack are SMS-PP Download messages Sep 20 15:51:52 But the cause there is quite different Sep 20 15:56:33 pessi: so it seems that SMS_RECEPTION_ACTIVATE and SMS_RECEPTION_DEACTIVATE not needed Sep 20 15:59:35 Jeevaka: I'm not on the map? Sep 20 16:00:36 pessi: By the way Is it the final solution, that isimodem driver wont pass any additional information for network specific errors to the core? Sep 20 16:00:55 while we are at the topic that I have a faintest clue, does someone have an idea how *31# and #31# should work with respect of fdn? Sep 20 16:01:00 dont Sep 20 16:01:37 Jeevaka: probably not, but nobody has bothered to do CERR conversion Sep 20 16:02:39 Actually we do Sep 20 16:02:40 incase of Send USSD failure case, isimodem driver calls CALLBACK_WITH_FAILURE with error type set to FAILURE and error code set to 0 Sep 20 16:02:46 See drivers/atmodem/atutil.c Sep 20 16:03:10 denkenz: isdn cause codes to cerr? Sep 20 16:03:55 Ok, so we do the conversion of +EXT/+CMS/+CME error codes Sep 20 16:04:05 We do not check CEER codes, but that needs to be polled separately Sep 20 16:04:14 e.g. after an ATD/CGDACT fails Sep 20 16:04:40 Jeevaka: what kind of error codesyou want? Sep 20 16:04:45 argh Sep 20 16:05:00 And CEER is extremely modem specific Sep 20 16:05:01 blinking irssi Sep 20 16:05:35 Also, I presume *31# and #31# are independent of the FDN number Sep 20 16:05:41 But I could be wrong Sep 20 16:06:12 the dial string is supposed to be part of fdn number Sep 20 16:06:50 EFfdn does mentioned SSC Sep 20 16:06:59 denkenz: I just mean that we get 1) internal modem error codes 2) mm error codes (ISDN cause codes) 3) various rose-rpc error codes (in case of ussd) Sep 20 16:07:06 However, there's nothing stopping you from ATD the FDN number with suppression / invocation Sep 20 16:07:07 for example USSD cases: error codes coming part of the FACILITY RETURN ERROR code Sep 20 16:07:07 regarding the *31# Sep 20 16:07:26 give me 2minutes for the *31# Sep 20 16:08:26 pessi: There's no facility within 27.007 to report them, unless the AT+CUSD request immediately returns that error Sep 20 16:08:52 CEER is not applicable to CUSD Sep 20 16:09:50 denkenz: I've no faintest clue how at modem returns errors, I'm just trying to say that isi drivers do not do any at-compatible error code coversion Sep 20 16:10:52 AFAIK the error codes are defined in 24.008 Sep 20 16:11:00 So they should be the same Sep 20 16:11:19 But then this is supplementary services, so who knows Sep 20 16:11:28 but in case of ussd, we could returns rose-rpc/MAP errors like code 16, IllegalSS-Operation Sep 20 16:12:06 denkenz: cool, so we could return cause codes if we receive them? Sep 20 16:12:27 In theory yes Sep 20 16:12:40 As long as they fit into the context of ofono_error Sep 20 16:12:47 Nothing uses them right now though Sep 20 16:13:53 and which error_type we should use with them? Sep 20 16:14:15 Right now we have CMS/CME/CEER/SIM Sep 20 16:14:15 pessi: This error codes may not be useful information to the user, but for SAT it is needed Sep 20 16:14:23 CMS/CME errors are taken directly from 24.008 Sep 20 16:15:13 Sorry, CEER are from 24.008, rest are from various sources Sep 20 16:15:28 Whether they map 1:1 with what your modem reports, I don't know Sep 20 16:15:28 we cant use CMS and CME errors Sep 20 16:15:28 better to have a new one Sep 20 16:16:00 Like what exactly? Sep 20 16:16:37 OFONO_ERROR_TYPE_SS ? Sep 20 16:16:48 yep, something like that Sep 20 16:16:54 How is it going to be reported though? Sep 20 16:17:02 On AT modems CUSD succeeds always Sep 20 16:17:10 CME is from 27.007, CMS is from 27.005 ???? Sep 20 16:18:35 Jeevaka: and what to do with lower layer errors, there are plenty of "problem" codes available? Sep 20 16:18:35 CMS comes from various specifications Sep 20 16:19:18 one example? Sep 20 16:19:40 24.008 and 27.005 Sep 20 16:19:58 sorry, 24.011 Sep 20 16:20:02 like SS_GSM_INVOKE_PROBLEM with SS_GSM_MISTYPED_INVOKE_PARAMETER Sep 20 16:20:03 27.005 and 23.040 Sep 20 16:20:39 Anyway, according to 27.007 CUSD can only return ME errors Sep 20 16:20:51 So not quite sure what can be done here Sep 20 16:22:02 Jeevaka: I suppose if you have garbled BER-encoded crap withing facility, you will get those "Problem" error codes Sep 20 16:22:14 Jeevaka: so I wonder if stk expects to see them Sep 20 16:22:34 denkenz: deprecate atmodem ;) Sep 20 16:22:35 if you check the ts 27.007, section 3.2.5, 0-127 comes from 24.011 and 128-255 comes from 23-040 rest in 27.007 Sep 20 16:22:35 sorry, rest in 27.005 Sep 20 16:22:37 or stk ;) Sep 20 16:23:01 Jeevaka: CMS? Sep 20 16:23:02 I would prefer to deprecate stk :-) Sep 20 16:23:36 Jeevaka: A3.2.5? Sep 20 16:23:36 CMS comes from 27.005, 23.040, 24.001 Sep 20 16:23:40 24.011* Sep 20 16:23:46 yes Sep 20 16:23:59 in 27.007? Sep 20 16:24:12 in 27.005 Sep 20 16:25:19 pessi: Hey I'm all for it Sep 20 16:25:38 pessi: But call me back in 2020 when you get non-AT command modems to be the standard ;) Sep 20 16:26:47 So far the only reason to include USSD error codes are for STK 'additional info' crap Sep 20 16:26:47 incase of lower layer errors, problem codes is sent as it is. in mistype paramater it is 2. so it is sent as it is to the STK Sep 20 16:27:13 Or is there another use case? Sep 20 16:27:14 as of now, i see it is the only thing Sep 20 16:28:00 if you wnt to do nice supplementary service settings ui, you need the error codes Sep 20 16:28:49 Like which ones? Sep 20 16:29:03 because you will have 3000 different operators each with different subscriptions and HLR/MSC implementations that screw you in different ways ;-/ Sep 20 16:29:04 may be in future, if there is an application which interprets this and displays some understandable information to the user Sep 20 16:29:09 And what is meant by supplementary service settings ui? Sep 20 16:29:21 CCFC/CCWA/Call barring? Sep 20 16:29:30 ui that lets you modify things like forwarding and call barring Sep 20 16:29:33 yep Sep 20 16:29:41 But those don't go through USSD Sep 20 16:29:49 but they use same error codes Sep 20 16:31:02 Heh, you want the UI to get exposed to the low level USSD error codes? Sep 20 16:31:59 unless if you want to do it in core? Sep 20 16:32:40 Shrug, if there's a real need sure Sep 20 16:32:48 But so far I fail to see one Sep 20 16:32:59 stk needs high-level ones, I have never seen low-level ones Sep 20 16:34:48 refer 31.124 specification section 27.22.4.12.5 Sep 20 16:38:23 pessi: incase of *31# will also go thorugh the fdn check Sep 20 16:38:24 pessi: Is this the one you wanted to know on *31# with respect to fdn? Sep 20 16:39:24 so *31# or #31# should be in fdn, if you want to dial with CLIR enabled or disabled? Sep 20 16:39:24 fdn check is done for all the supplementary service string Sep 20 16:40:49 Jeevaka: iow, if I have #31# in FDN, can I call #31#+18005551234 ? Sep 20 16:40:49 if you mean call to a specific number Sep 20 16:41:10 And where do you find this info? Sep 20 16:41:41 Specifically, on AT modems you can invoke CLIR suppression/invocation without a USSD string Sep 20 16:41:42 as I know, fdn is prefixed one Sep 20 16:42:33 This also means harmless things like CLIP provisioning checking must be in FDN Sep 20 16:42:39 If so, then this feature is pointless Sep 20 16:42:39 lets say you are dialing a number 0123456*, then its enough to store 0123 in the fdn Sep 20 16:43:08 ??!?! Sep 20 16:43:08 any number starting with 0123 will be allowed Sep 20 16:43:16 Where are these rules Sep 20 16:44:02 Jeeveka: is there something else besides 31.102 4.2.24? Sep 20 16:45:03 like some test cases? Sep 20 16:46:12 The only case I know of wildcarding is when the 'D' character or whatever is present in the SSC string Sep 20 16:46:12 Fixed Dialing Numbers is a feature that allows the phone to dial only certain numbers or number with certain prefixes Sep 20 16:47:15 wildcarding is for cases where you have codes in the middle I guess Sep 20 16:47:16 lets say you have stored +358 in fdn, then you dial any number starting with +358* Sep 20 16:47:20 wilds Sep 20 16:47:50 this.feature.is.utterly.pointless ;) Sep 20 16:48:04 And I still want the spec where this is said Sep 20 16:48:30 ok, let me find it for you, I dont remember it now Sep 20 16:49:43 22.101 A.24 has something Sep 20 16:50:46 "Allow the extension of an FDN entry by adding digits to the Fixed Dialling number on a per call basis." Sep 20 16:51:51 sorry, A.25 Sep 20 16:53:03 Prevent the establishment of bearer services/teleservices to destination addresses which are not in FDN entries Sep 20 16:53:06 on a per bearer service/teleservice basis. The list of bearer services/teleservices excluded from the FDN check Sep 20 16:53:09 shall be stored in the SIM/USIM. Those bearer services/teleservices are characterised by their service code as Sep 20 16:53:12 described in [23]. For instance if the SMS teleservices is indicated in this list, SMS can be sent to any Sep 20 16:53:15 destination. By default, the ME shall prevent the establishment of any bearer service/teleservice to destination Sep 20 16:53:18 addresses which are not in FDN entries. Sep 20 16:53:20 do you have any idea what this might mean? Sep 20 16:53:31 Nope ;) Sep 20 16:54:02 [23] is map Sep 20 16:55:24 Ok, it seems that FDN can have an entry in the EFccp field Sep 20 16:56:10 The format of EFccp -> go hang yourself now, you won't understand it Sep 20 16:56:10 atleast what I know is, if we start doing the fdn check in the ofono, then the code becomes mess Sep 20 16:56:10 :-) Sep 20 16:56:48 EFccp can actually specify the bearer parameters, e.g. this is allowed for CSD calls, SMS, et Sep 20 16:56:48 c Sep 20 16:56:48 there are plenty of cases has to be considered Sep 20 16:56:49 for example, ones coming from SAT shouldn't checked for FDN Sep 20 16:58:05 Jeevaka: nääh, boolean ofono_fdn_check_dest(char const *destination) { return FALSE; } Sep 20 16:58:54 or you have to check for EFecc prefixes ;-/ Sep 20 16:58:54 pessi: why are we discussing this, are you thinking of doing fdn check in ofono? Sep 20 17:00:06 oh, the fdn check needs the dial string Sep 20 17:00:27 yep Sep 20 17:00:34 and i wonder what else it need Sep 20 17:00:37 s Sep 20 17:00:54 And I don't quite frankly see anything about allowing numbers with a prefix Sep 20 17:01:15 Unless the cryptic "allow the extension of an FDN entry by adding digits..." thing applies here Sep 20 17:01:47 yep Sep 20 17:02:21 Which is pointless if you also have wildcards Sep 20 17:02:22 http://www.phonescoop.com/glossary/term.php?gid=253 Sep 20 17:02:30 if it was said clearly in 3gpp sepc, it would take all the fun out of making a phone Sep 20 17:02:30 check the above link Sep 20 17:02:30 Or wildcards are pointless if you have this Sep 20 17:02:30 http://en.wikipedia.org/wiki/Fixed_Dialing_Number Sep 20 17:03:17 Honestly, there more I think about it, the more I say we just check FDN Sep 20 17:03:24 If enabled, go into emergency mode and forget this crap Sep 20 17:03:45 There are so many stupidities here its not funny Sep 20 17:04:47 By the time you're done, you probably wrote more code than exists in the core today Sep 20 17:06:11 yes, its not only fdn it also applies to call control Sep 20 17:06:47 denkenz: I agree with you here. Lets forget about FDN. If it is enabled => emergency mode, done. Everything else in insane. Sep 20 17:07:11 denkenz: can't you first take my huawei patches and I can start improving huawei from that? it sucks that huawei is broken right now Sep 20 17:07:51 There are other more important features in my book that should work in a telephony stack from 2010. FDN is not one of them ;) Sep 20 17:07:51 pessi: I think its the same case in N900 Sep 20 17:08:14 Jeevaka: hm? "it sucks"? Sep 20 17:08:15 Pessi: sorry, its different in N900 Sep 20 17:08:33 holtmann: Can you apply kvalo's patches for me? my Repo is filled with SMS changes Sep 20 17:08:48 Are you fine with both patches? Sep 20 17:08:57 The huawei plugin needs to be reworked in a major way anyway Sep 20 17:08:59 I haven't even looked at them. Sep 20 17:09:25 They're not perfect, but if it gets people semi-kinda working, that's fine Sep 20 17:09:28 Jeevaka: I'm a bit slow today... what is different? Sep 20 17:10:19 denkenz: Okay. Sep 20 17:10:19 pessi: In N900 fdn check is done but it doesn't show me the numbers in FDN. Sep 20 17:10:40 sure. yes. the check is done by modem. Sep 20 17:11:07 there is a D-Bus API to fetch numbers, but no UI Sep 20 17:11:20 kvalo: Done. Sep 20 17:11:36 can we do the same with ofono Sep 20 17:11:50 holtmann: thanks. I'll start improving huawei bit by bit Sep 20 17:12:36 Jeevaka: You really don't wanna give up in FDN, do you ;) Sep 20 17:12:36 FDN check if needed has to be done in modem side? Sep 20 17:12:50 Jeevaka: sure, if you just prepresent EFecc2 as a binary blob? Sep 20 17:13:06 denkenz: if you have any ideas how huawei really should work, I'm all ears :) I will check mbm first. do you have any other pointers? Sep 20 17:13:06 its because of the operator requirement Sep 20 17:14:32 kvalo: see how MBM handles this Sep 20 17:14:46 kvalo: Basically it uses CPIN? to check sim presence Sep 20 17:14:59 kvalo: Then inside drivers/atmodem/sim.c there's an MBM quirk Sep 20 17:15:16 kvalo: I suggest moving the SIMST:1 listener there Sep 20 17:15:44 kvalo: That should in theory support both locked and unlocked sims Sep 20 17:15:59 kvalo: Might have to tweak it for huawei specifically (maybe SYSINFO instead of CPIN?) Sep 20 17:16:00 Holtmann: For modems which does the FDN check by its own, then we will end up in emergency mode which doesn't seem to be correct Sep 20 17:16:16 All modems in existence support FDN Sep 20 17:16:28 What we can do is simply run a query and force emergency mode in oFono Sep 20 17:16:42 e.g. we do not initialize any atoms outside voicecall and sim Sep 20 17:16:49 And we only allow emergency calls Sep 20 17:16:54 denkenz: ok, thanks Sep 20 17:17:54 denkenz: and we do not sell any phones via operators Sep 20 17:18:43 If your operator is selling smart phones with FDN enabled Sep 20 17:18:50 FDN on a smartphone makes no sense. I mentioned that multiple times. Sep 20 17:18:53 Then your operator needs to check their marketing strategy Sep 20 17:19:25 If you happen to stick a FDN enabled SIM in your smartphone, then you get what you asked for, piece of expensive paper weight. Sep 20 17:21:22 Seriously, FDN is looking more and more like a fool's errand Sep 20 17:21:35 You have so many interactions in the system because of it, it is seriously not funny Sep 20 17:22:06 what are the interactions? you pass stuff into modem, modem says yes or no? Sep 20 17:22:13 Nope Sep 20 17:22:21 For STK you need to bypass FDN checks Sep 20 17:22:29 On AT modems you got no control over that Sep 20 17:22:31 -> FAIL Sep 20 17:22:55 atmodems -> FAIL in general, but you have a point Sep 20 17:23:35 Nobody would welcome the death of AT modems more than me Sep 20 17:23:45 I've dealt enough with them for a lifetime ;) Sep 20 17:24:34 However, other possible issues: you have to set FDN either via Phonebook or EFfdn access Sep 20 17:24:34 agree, on AT modems its difficult Sep 20 17:24:41 EFfdn access required PIN2 Sep 20 17:24:52 Entering PIN2 is vendor-specific or not possible Sep 20 17:24:59 Same goes for EFbdn Sep 20 17:25:40 reading fdn goes nicel without PIN2 Sep 20 17:26:02 Sure, because 31.102 says READ: PIN, Update: PIN2 for EFfdn Sep 20 17:26:25 But if we go through all the pain of supporting FDN, then we should at least make it writable Sep 20 17:26:33 Not to mention the same for BDN Sep 20 17:26:44 So seriously, it'll be 2014 when you're done Sep 20 17:27:41 then we have lte-only modems and all the world has IPv6 Sep 20 17:27:59 so let's drink for the universal deployment of the IPv6 Sep 20 17:28:08 sorry. mobile IPv6 Sep 20 17:28:33 Do you believe all the marketing material they send you? If so, I've got some land in West Texas... ;) Sep 20 17:30:33 I've been carried a small bucket of sand around for last 15 years, just in case I'd come accross the last MSC so I could perform the appropriate rites ;) Sep 20 17:31:33 so, with fdn enabled, ofono goes into emergency code and we will stick with it Sep 20 17:31:33 I agree to this Sep 20 17:31:56 pffft Sep 20 17:32:46 lol Sep 20 17:34:43 sent patch for a fdn-api Sep 20 17:35:03 You know the answer though.. Sep 20 17:35:25 "Thanks. Applied" ;-) Sep 20 17:36:09 bzzt Sep 20 17:36:45 it has enable-disable a'la Marcel Sep 20 17:37:17 Shrug, I'm fine allowing [readonly] property on Sim interface for FDN Sep 20 17:37:28 So that if we're in emergency mode we have a clue why Sep 20 17:37:55 But until the rest of the concerns are solved, I don't think pushing this feature is wise Sep 20 17:39:08 why do you think at+clck="FD",0,"tilu" should not work? Sep 20 17:39:09 Pessi, denkenz: whats the conclusion for SS error codes? Sep 20 17:39:49 And what if it is the opposite? Sep 20 17:40:11 I'd add OFONO_ERROR_TYPE_SS Sep 20 17:40:15 Jeevaka: I don't see how that can be implemented Sep 20 17:40:24 unless you send an error in ofono_ussd_notify Sep 20 17:40:25 denkenz: you get what you ask for Sep 20 17:40:46 pessi: Except that you don't, because the rest of the system doesn't deal with FDN properly Sep 20 17:44:44 and what we need to deal with FDN properly? Sep 20 17:45:25 if modem has requested STK to make call, it will allow the call? Sep 20 17:45:32 nope Sep 20 17:45:32 simplest option incase of SS error codes : STK sends no additional info for both isimodem and atmodem. Sep 20 17:45:53 denkenz: I'd pick low-hanging fruits Sep 20 17:46:01 add disable Sep 20 17:46:24 pessi: Exactly, which is why I don't want to deal with FDN Sep 20 17:46:33 pessi: So if we detect FDN, we are stuck in emergency mode Sep 20 17:46:42 We can add disable, but not enable Sep 20 17:47:26 However, from an API perspective that makes no sense Sep 20 17:49:09 well, SetProperty can return NotAllowed or what ever if app tries to enable Sep 20 17:50:12 I can deal with that, but put it on the sim interface Sep 20 17:50:32 SIM SetProperty does not take password Sep 20 17:50:41 so I'd model it after barring Sep 20 17:50:59 even if it has only half a method Sep 20 17:51:17 The problem is sim needs to check the fdn state Sep 20 17:51:30 Before going to sim ready state Sep 20 17:51:49 it has to check plenty of other things, too. Sep 20 17:51:58 Sure, but all within the sim atom Sep 20 17:52:10 Going cross-atom is a bit nasty Sep 20 17:52:19 we are doing that with ss stuff Sep 20 17:52:28 Not on sim initialization Sep 20 17:52:41 That part is hairy enough Sep 20 17:53:24 Is it really that important to disable fixed dialing ? Sep 20 17:53:56 it will grow warts, you know it ;) Sep 20 17:54:19 I don't get the reference Sep 20 17:54:24 So I assume 'no' ;) Sep 20 17:55:16 I would put the ready checking into driver Sep 20 17:55:30 because only the driver know all the warts of the particular modem Sep 20 17:57:05 there are too many reasons why a modem might not support the particular SIM or the the features that are enabled on it Sep 20 17:57:31 The driver already knows this Sep 20 17:57:44 if it signals sim_inserted, then the SIM is ready to be probed for always readable entries Sep 20 17:58:05 After that the CPIN entry is tricky, but even then the drivers have some control Sep 20 17:58:11 Or will once we have sim_ready notifications Sep 20 17:58:30 oFono does not really assume or try to do anything tricky here Sep 20 17:59:00 Besides, FDN enabled / disabled flags are supposed to be set in EFsst / EFest Sep 20 18:01:07 but there is a cooked inteface Sep 20 18:07:06 There is one for MSISDN too Sep 20 18:07:10 Doesn't mean we use it Sep 20 18:07:19 Anyway, for FDN I'm open to checking using CLCK Sep 20 18:07:27 But it should still be on the sim interface Sep 20 18:07:36 Writing a separate atom for this is not worth it Sep 20 18:21:13 denkenz: any review comments on the lanuguage notification proactive command patch? Sep 20 18:22:31 It looks fine, but I'm in the middle of something and can't push Sep 20 18:22:46 I'll apply it later this week Sep 20 18:24:22 ok Sep 20 18:27:59 what to do with the Send USSD additional information, can I just send no additional information for both isimodem and atmodem? Sep 20 18:30:18 Just do the 'No cause can be given' for now Sep 20 18:30:29 ok Sep 20 18:43:05 Hello denkenz & marcel, I want to understand the callhisory agent idea that you are proposing . Can you please elaborate that? Sep 20 18:54:03 raji: Basically see the various agent APIs in ConnMan/oFono/BlueZ Sep 20 18:54:14 Generally there's a RegisterAgent, and UnregisterAgent Sep 20 18:54:43 on the oFono side, plus the Agent API that the application must implement Sep 20 18:54:51 Whenever something interesting happens, the Agent is called Sep 20 18:55:35 so e.g. a missed call would be an Agent method call 'RecordMissedCall' or something Sep 20 18:57:12 raji: So you could rely on Agent returning from each method call as an indicator that the data has been stored Sep 20 18:57:27 An error from the agent or no agent being registered means you have to buffer the data Sep 20 19:02:25 I will take a look at ofono agent api first and will get back if more questions. thanks Sep 20 22:16:15 denkenz, is stkagent.* example for the agent api? Sep 20 22:35:46 raji: yep Sep 20 22:42:33 denkenz, Does dailer needs to register with the agent and listen for the events? how does dialer needs to interact with the agent? Sep 20 22:42:53 I am not able to understand that part from looking at the stk code Sep 20 22:43:32 raji: no dialer is the agent Sep 20 22:44:00 raji: e.g. if the current call history consumer is the dialer, then the dialer would implement an agent and register that object with oFono Sep 20 22:44:24 raji: Essentially instead of dialer pulling the info, it is getting pushed Sep 20 22:47:04 Oh, so callhistory just sees if the agent is up or not, if up then calls the methods with information, otherwise stores it in the disk file , pushes all the data when Sep 20 22:47:17 the agent is up. I see what you are saying. Sep 20 22:47:38