**** BEGIN LOGGING AT Thu Sep 16 02:59:57 2010 Sep 16 03:08:45 denkenz: So you also agree on the proposal from jeevaka, which means I have to duplicate a lot of functions and some data structure? Sep 16 03:09:57 I'm not sure there is going to be a lot of duplicating... Sep 16 03:10:27 Your STK response builders are going to be totally different from the DBus response builders Sep 16 03:12:19 yes, but the difference now shows in ussd_initiate() and handle_send_ss_command(), and various call back functions. Sep 16 03:14:03 If we register separate handlers for STK, I have to duplicate recognized_control_string(), recognized_passwd_change_string() and ss->ss_control_list, ss->ss_passwd_list first. Sep 16 03:15:02 I'm actually wondering whether handling passwords is needed Sep 16 03:15:20 Without it, the recognized_control_string becomes trivial Sep 16 03:16:02 This part I'm not sure. My thinking is that changing password is some kind of valid ss string. Sep 16 03:17:40 maybe, I don't know Sep 16 03:17:41 If we reuse current functions, we may even get the power of oFono on some advanced feature, such as the interrogation of groups of ss. Sep 16 03:17:56 I've never seen an example of this in the stk test spec Sep 16 03:18:09 Yeah, that is actually definitely not what we want Sep 16 03:18:23 The STK response cannot support that Sep 16 03:19:05 Oh, yes, we can't fill in the additional information. Sep 16 03:20:10 But if we have separate handling of stk, we'd also duplicate all related functions in .c Sep 16 03:21:03 such as cb_ss_control(), though we can extract most of it as a utility function. Sep 16 03:21:04 not really, you can split out the common logi c Sep 16 03:22:25 We may also need to duplicate all those callbacks, such as cb_ss_set_lock_callback(), cb_ss_query_next_lock(), cb_ss_query_next_lock_callback(), etc. Sep 16 03:22:40 All of them will have a copy, specific for stk Sep 16 03:22:50 And you're already adding stk atom watches, so running the register to stk is actually ok Sep 16 03:23:19 Most of the logic for parsing ussds and dispatching can be put into a utility file Sep 16 03:23:37 And the callbacks are going to be completely different anyway Sep 16 03:23:46 Since you need to build the additional information object Sep 16 03:26:44 I think the atom driver will always pass the additional information to the core. Or we will have to duplicate a copy for stk in atom driver. Sep 16 03:27:58 Unfortunately you will have to synthesize the additional information Sep 16 03:28:07 The driver will not pass up anything Sep 16 03:29:04 I don't quite understand this part in the spec. Sep 16 03:29:21 I wonder how can I get the information from network. Sep 16 03:29:37 You get the information from the network, but the modem interprets it for you Sep 16 03:29:46 And sends you back the info as e.g. CCFC: Sep 16 03:29:59 So we'll not get these information from modem? Sep 16 03:30:15 You actually need to take the CCFC info and synthesize the network response Sep 16 03:30:42 Something like Network -> PDU -> Modem -> CCFC -> oFono -> PDU -> SIM Sep 16 03:31:12 This is why Send SS is always implemented by the modem ;) Sep 16 03:31:21 Do you mean the returned at command contains all the information we want? Sep 16 03:31:51 Maybe not always, but for the most part yeah Sep 16 03:32:50 Then do we have spec to describe the CCFC? Or it's modem specific. I don't see enough information is returned from 27.007. Sep 16 03:33:36 24.080 Sep 16 03:33:58 This part is basically nasty Sep 16 03:34:14 And you might want to just run away screaming now ;) Sep 16 03:34:21 OK, I will read the spec. Sep 16 03:34:32 heh, I don't Sep 16 03:35:16 Most of the spec are complicated for me. I spent a few days to read someones related to supplementary service. Sep 16 03:35:53 I also remember I spent a whole day to read 31.009 to know something related to sim initialization:) Sep 16 03:36:53 Turning back to send ss support, why do you think my current solution is not good? Sep 16 03:37:27 You don't like the structure to contain both the dbus message and stk request? Sep 16 03:38:48 Nope Sep 16 03:38:58 Because in the end it won't help you Sep 16 03:39:12 composing the additional info object will be lots and lots of code Sep 16 03:39:37 So you might as well keep the DBus path and the STK path separate Sep 16 03:40:27 Check 31.124 for examples of Send SS responses Sep 16 03:40:38 Along with 24.080 you shall see what is needed Sep 16 03:41:24 I see your concern here. I will read the spec to see if I will change my mind;) Sep 16 03:41:31 You might want to start small, e.g. focus on call forwarding first Sep 16 03:42:04 good suggestion:) Sep 16 03:42:21 I will get back to you after I read the spec. Sep 16 03:42:29 nod Sep 16 03:42:52 Reading the spec cover to cover might not be the fastest approach Sep 16 03:43:11 I'd start with 31.124 and see if you can decode the TLVs Sep 16 03:43:25 Writing a unit-test style test app might be good here Sep 16 03:44:14 Oh, wait a minute. Sep 16 03:44:55 I have read the spec 24.080. Sep 16 03:45:25 And understand the Facility information element. Sep 16 03:45:59 But what I'm not sure now is whether modem will return enough info to us. Sep 16 03:46:18 It seems this spec doesn't describe the at command format. Sep 16 03:46:47 27.007 does Sep 16 03:46:47 Where can I find the returned at command format? such as in 27.007 Sep 16 03:47:04 Or you can simply see include/call-forwarding.h Sep 16 03:47:44 That is a 1:1 map to 27.007 Sep 16 03:49:25 Do you mean the returned at command with mode 2 (query)? Sep 16 03:49:52 the only time information is actually returned is on a query Sep 16 03:50:05 The rest the modem responds with OK or CMS/CME error Sep 16 03:53:30 So the current problem is query callback functions don't have all the info pass from atom driver to core. Am I right? Sep 16 03:54:22 I need to return these info to core and compose them as additional info and send them to sim. Sep 16 03:54:47 No, what the driver returns today is as much as you get Sep 16 03:55:01 You have to take that info and 'fake' the network reply Sep 16 03:55:10 If this is not possible, then tell me and we punt this task Sep 16 03:57:34 In my current solution of callback function, I say if our request is from dbus, we reply the dbus; if the request is from stk, we send the response. Sep 16 03:58:28 All the problem for me now is I don't make full use of these info to compose a response with enough additional info. Sep 16 03:59:05 I can easily follow my current way and extend the response. Sep 16 03:59:51 I may write a utility function to help me compose all kinds of response, and get it called by various callback functions. Sep 16 04:00:15 During the situation we have request from stk. Sep 16 04:00:54 I still don't see a need to separate the path of dbus and stk. Sep 16 04:01:27 But if you all think the separation is a good idea, I may have a try. Sep 16 04:02:25 I don't like the ofono_ss_req parameter Sep 16 04:02:46 I'd rather see two independent paths, makes the code easier Sep 16 04:03:00 In the end, I don't care if we write more code, as long as it is easier to follow Sep 16 04:03:40 ok. I will separate the path and start from someone easy, such as call forwarding. Sep 16 04:04:13 I have another question on wiki Sep 16 04:04:33 Michael would help on wiki in oFono website. Sep 16 04:04:52 And do you have some preference on wiki server? Sep 16 04:05:13 Do we need some full feature wiki server, such as mediawiki? Sep 16 04:05:47 doubtful Sep 16 04:05:53 He ever helped on wiki at syncevolution. Sep 16 04:06:28 If that one is OK, then it would be easy for him to duplicate the configuration on oFono website. Sep 16 04:06:49 i can't imagine us doing much more than formatted text Sep 16 04:07:21 so that sounds fine to me Sep 16 04:07:51 OK. I will reply him we're OK with the one with syncevolution. Sep 16 06:04:48 yang_office, denkenz: Final decision on Send SS is to have separate paths for normal use case and STK use case, right? Sep 16 06:39:34 Jeevaka: yes. Denis is at the same side with you. I don't want to be left alone at the other side, so I have to modify the patch;) Sep 16 09:12:20 yeah, huawei is broken even with sim pin query disabled :/ Sep 16 09:12:34 ...when using connman Sep 16 11:10:07 pekka: ping Sep 16 11:26:22 pong? Sep 16 11:38:10 Are you going to resubmit the n900 patches? Sep 16 11:39:26 yes Sep 16 11:39:41 you have nothing better to do but review patches? ;-) Sep 16 11:49:19 hehe, no. Not after my SMS agent deflected. ;) Sep 16 12:07:03 holtmann: the meego-arm guys want to have /etc/ofono/modem.d/ Sep 16 12:07:25 pessi: What should be that for? Sep 16 12:07:51 device-specific configs Sep 16 12:08:09 No. We can do that all via udev rules. Sep 16 12:08:19 No extra configs. Sep 16 12:08:32 assuming we have working udev ;-) Sep 16 12:08:43 If not, than that needs to be fixed anyway. Sep 16 12:08:47 sure Sep 16 12:08:58 Running oFono on a system without udev is rather pointless. Sep 16 12:09:53 And as I mentioned on the mailing list some time ago. We will remove /etc/ofono/modem.conf. Sep 16 13:52:39 denkenz: sent your const review patch Sep 16 14:21:26 yang_office, denkenz: decision on Send SS is to have separate paths for normal use case and STK use case, am i right? Sep 16 14:21:46 yes Sep 16 14:23:33 ok, do we need to post this to the mailing list? basically to avoid anybody sending review comments on the old patch Sep 16 14:24:41 Almost everyone who has ever reviewed patches is on IRC Sep 16 14:25:01 ok, then its fine Sep 16 14:39:37 akiniemi: btw, gprs will crash when modem is put into offline Sep 16 15:18:25 denkenz: any reason not to pass the ussd state to driver? Sep 16 15:19:20 or forget about it Sep 16 15:20:48 why? ... ok Sep 16 15:48:27 denkenz: I need some help. do you know what changes the state from HUAWEI_SIM_STATE_INVALID_OR_LOCKED to HUAWEI_SIM_STATE_VALID? it's not clear to me Sep 16 15:49:04 is there a command which triggers the state change? Sep 16 15:50:02 if I "warm start" the modem, I get the valid state. but if "cold start" it, it stays in invalid. Sep 16 15:53:04 pessi: no surprise, as it predates online/offline by a couple of months :) Sep 16 15:53:09 pessi: got a trace? Sep 16 15:54:16 pessi: btw, patch 1/5 of n900 has a weird commit ID Sep 16 15:54:48 Actually 1-3 are like that Sep 16 15:55:22 commit id? Sep 16 15:55:26 ppessi@hamsa? Sep 16 15:55:54 kvalo: I think the modem performs sim initialization Sep 16 15:56:05 kvalo: So it takes time for it to go from invalid to valid Sep 16 15:56:33 If the SIM is locked, then it gets even more tricky, since the modem has to delay the initialization until the PIN is entered (everything is encrypted) Sep 16 15:56:59 In theory, the ^SIMST notification should tell you, but I think on some firmware Huawei doesn't send this one at all Sep 16 15:58:08 denkenz: in the cold start case I added a busyloop checking sim state, but I see no changes from the invalid even after 20 seconds. Sep 16 15:58:17 pessi: yup Sep 16 15:58:31 my laptop Sep 16 15:58:48 Is your PIN locked? Sep 16 15:58:55 denkenz: I'll compare the logs more carefully Sep 16 15:59:10 denkenz: no, I'm first trying to get the unlocked case working again Sep 16 15:59:49 Then it might be that Huawei needs an explicit CFUN=1 to get it to start initializing Sep 16 16:00:07 thanks, I'll test that Sep 16 16:06:01 pessi: yeah, can you git config --global it into a real email address? Sep 16 16:07:43 it is now Sep 16 16:07:54 don't worry Sep 16 16:34:56 denkenz: if you do mo ussd, and get notify, state goes to idle Sep 16 16:54:27 denkenz: I'll post some more ismodem ussd fixes Sep 16 16:56:50 pessi: I have some comment on ussd Sep 16 16:57:02 go ahead+ Sep 16 16:57:31 pessi: If we get a notify after MO ussd, then as per specification no further information needed Sep 16 16:57:46 yep Sep 16 16:57:59 but I'd like to cancel such a session Sep 16 16:59:41 ok Sep 16 17:00:15 ok, so when a cancellation comes ofono ussd will be in idle state instead of active state Sep 16 17:00:26 yes Sep 16 17:00:43 and we still have the mo-request pending Sep 16 17:04:18 as per the specificatin 24.090, if network doesn't request any information, it will send the release complete with the message Sep 16 17:04:28 yes Sep 16 17:04:38 but if it does not? Sep 16 17:05:07 and it seems to me that crappy Nokia network or crappy Nokia modem can send Notify while mt-request is pending Sep 16 17:07:29 so the fix that you are going to do is in isimodem not in the core Sep 16 17:07:42 hm? Sep 16 17:08:53 did I understand it wrongly Sep 16 17:10:02 I'd like to cancel all the time there is an ussd session, not only when nw is prompting user for new information Sep 16 17:12:25 there are all kind of demented use cases in http://www.wirelessmodemapi.com/?q=node/50 Wireless mModem API G2 V1.10w33.zip and file i_ss_wm_p.pdf Sep 16 17:13:00 sorry, account required. and you have to sell your soul to Jorma in order to access the zip Sep 16 17:15:15 ok Sep 16 17:19:34 I'll go through the document Sep 16 17:19:53 I have also one question on isimodem related to SIM Sep 16 17:21:31 sure Sep 16 17:24:09 isn't there any indication to inform whats the SIM application currently active Sep 16 17:24:17 pessi: The AT modem spec does not really allow multiple USSD session Sep 16 17:25:51 there is only one session, but while client has a pending puSS-request, network can send multiple uSS-Request and uSS-Notifys Sep 16 17:27:00 it is all explained clearly in the note 2 of the figure 6.2 in 24.090 Sep 16 17:27:24 or at least mentioned ;-) Sep 16 17:27:25 Sure, but the modem firmware then has to deal with it, the spec in 27.007 says nothing of this Sep 16 17:27:58 The best oFono gets told is that the firmware responded to a USSD Sep 16 17:28:05 Jeevaka: like 2g or 3g? Sep 16 17:28:10 yes Sep 16 17:28:32 CUSD makes no distinction between MO or MT USSD sessions Sep 16 17:29:09 that is why you keep ussd->state, I guess? Sep 16 17:29:17 Jeevaka: On an AT modem there is a way, it is a bit nasty, but depending on 3G vs 2G, the GET RESPONSE format will be different Sep 16 17:29:24 pessi: Correct Sep 16 17:31:01 EFdir is another option Sep 16 17:32:18 You can try, but most modems do not implement directory selections Sep 16 17:32:35 We're having issues selecting EFimg files on some modems for crying out loud Sep 16 17:32:39 EFiidf rather Sep 16 17:36:50 ok Sep 16 17:37:48 27.007 does have some commands for sim application selection, feel free to poke those Sep 16 17:37:54 But I've never seen a modem that implements them Sep 16 17:39:03 I dont have modems which supports CSIM Sep 16 17:41:38 Only some old Ericssons do AFAIK Sep 16 17:41:58 The Freerunner does, but its not even 3G Sep 16 17:42:23 And CSIM is not fun ;) Sep 16 17:43:13 yes, agree its not fun. have experienced when working with BTSAP Sep 16 17:50:26 Jeevaka: hm, looks SIM_READ_TABLE_REQ returns 2G/3G information Sep 16 17:50:32 is it needed for something? Sep 16 17:51:02 the old api used in n900 does not allow reading from any ef (bu ef_iccid) Sep 16 17:51:15 you have to use cooked requests instead Sep 16 17:54:39 currently we are relying on phase information failure code to reinterpret or issue file read requests Sep 16 17:54:50 and you can list and select apps with SIM_APP_SELECTION_REQ Sep 16 17:54:54 in core? Sep 16 17:54:57 yes Sep 16 17:55:23 uhoh Sep 16 17:55:57 if i believe atleast some modems will indicate selected application or atleast will provide options for quering application chosen Sep 16 17:58:26 Since the core doesn't know the application chosen, it issues read twice for some of the sim files. atleast one I know is EFecc Sep 16 18:06:53 yeah, few others like EFust/EFsst Sep 16 18:07:49 currently we have some limited number of files read, so it is not creating headache Sep 16 18:09:01 denkenz, pessi: do you have any proposal for handling this issue? Sep 16 18:09:32 are you sure this is a big deal? Sep 16 18:09:45 We stat a few files twice, that's it Sep 16 18:11:38 yes, but it can be avoided by having the application chosen Sep 16 18:12:48 agreed, but there is no way on an AT modem Sep 16 18:13:10 unless you take the get response data and determine 3g vs 2g format Sep 16 18:13:35 certainly we can let the driver tell oFono... Sep 16 18:13:49 other way is to force the modem providers to inform ofono of the application chosen Sep 16 18:14:11 that would be fine Sep 16 18:14:22 thats my point, driver informing the ofono about the application chosen Sep 16 18:14:23 sounds neat, but we also have to support modems that providers don't give a shit about Sep 16 18:14:47 And there are modems that don't support CRSM at all (e.g. Option) Sep 16 18:15:34 I'm fine having the driver tell oFono the phase, if you can make it work Sep 16 18:15:36 simple, if the modem providers want to use ofono then they need to provide support Sep 16 18:15:49 Not really how it works with Linux ;) Sep 16 18:15:56 ok Sep 16 18:16:06 :-) Sep 16 18:19:58 may be we can provide an interface by which drivers can inform the core about application chosen. for modems not supporting this we will fallback to EFphase Sep 16 18:21:00 I'll think about the other possible options also Sep 16 18:21:22 Actually we don't rely on EFphase at all Sep 16 18:22:13 The only place that is used is in EF disk cache Sep 16 18:22:31 service table cache* Sep 16 18:23:38 Ok, two places ;) Sep 16 18:24:04 because for EFust/EFsst we can't guess the format Sep 16 18:31:41 I'll look into options Sep 16 18:50:18 pessi: nice, n900 worked out of box with connman Sep 16 18:50:41 pessi: damn, the connection was really bad Sep 16 18:51:05 it worked only for few seconds at a time and then it would not transmit anything for 20s or so :( Sep 16 18:57:25 pessi: So is there a need for modemconf changes? Sep 16 18:57:32 and connman didn't set dns servers :/ Sep 16 18:57:43 Remember modemconf is considered depreciated and we're actually wanting to get rid of it Sep 16 19:03:00 pessi: Another whacky idea, but can isigen and n900 be merged? :) Sep 16 19:38:40 denkenz: i have sent the patch on language notification simulation incorporating your review comments Sep 16 19:43:22 ok its applied, thanks **** ENDING LOGGING AT Fri Sep 17 02:59:57 2010