**** BEGIN LOGGING AT Fri Sep 10 02:59:57 2010 Sep 10 03:00:38 Yeah, that's a roundabout way of doing it Sep 10 03:00:40 Fixed Sep 10 03:07:54 balrog-k2n: about the Send DTMF Sep 10 03:08:11 Can we do the tone validation up front? Sep 10 03:08:29 Like in stkutil even Sep 10 03:10:30 Also, your DTMF tones are not valid, you need to convert * and # properly Sep 10 03:11:35 denkenz: i think there are 16 possible tones, no? Sep 10 03:11:42 Not in GSM Sep 10 03:11:52 'A' -> '*' Sep 10 03:11:55 'B' -> '#' Sep 10 03:12:01 C -> Control digit separator Sep 10 03:12:06 D -> "Wild" Sep 10 03:12:06 so D, E, F are invalid? Sep 10 03:12:09 E -> RFU Sep 10 03:12:16 F -> Endmark in case of odd number of digits Sep 10 03:12:35 So yeah, in this context DEF are invalid Sep 10 03:12:36 oh yeah, we'll never have F in the input in stk.c Sep 10 03:12:47 i'll fix this Sep 10 03:13:15 It also seems to me like waiting for 3 seconds per dtmf is a bit harsh Sep 10 03:14:44 the period is fixed for GSM, but honestly i haven't checked whether it was 3s Sep 10 03:14:54 i've seen 2s somewhere in the docs Sep 10 03:15:24 I'd say its more on the order of 100ms Sep 10 03:15:55 hmm, i'll check what it is exactly Sep 10 03:16:00 the pasue is always 3s Sep 10 03:16:10 The pause sure Sep 10 03:16:21 However, pause is not a valid character for DTMF Sep 10 03:16:33 So you have to be careful there Sep 10 03:16:45 ATD uses 'p' or ',' for pause Sep 10 03:17:07 If you try to send 'C' it will result in a 'C' DTMF ;) Sep 10 03:17:16 i've seen ',' in the docs, but not 'p' Sep 10 03:17:33 however i found no way to cause it to wait until call is connected Sep 10 03:17:35 manufacturer specific, most accept 'p' or 'P' Sep 10 03:18:59 btw. anything that comes after * is called the subaddress, maybe SetUpCall should send the subaddress by appending it after a '*' to ATD Sep 10 03:19:33 * is a valid dialing digit Sep 10 03:20:09 I say don't worry about the subaddress for now Sep 10 03:20:25 Lets get the simple cases working first Sep 10 03:20:44 ah, apparently it's manufacturer specific Sep 10 03:21:16 when you google "atd subaddress", you get different docs come up, some use ATDaddress|subaddress, others use ATDaddress/subaddress Sep 10 03:23:33 Yeah, and 27.007 doesn't even describe it Sep 10 03:23:45 At least V250 describes ',' as the official pause character Sep 10 03:24:09 Note that S8 displays the duration of the pause Sep 10 03:29:49 balrog-k2n: On STE the default duration is 70ms Sep 10 03:32:43 and STE does not support sending pauses in ATD Sep 10 03:32:45 denkenz: i think that's only for ATD though Sep 10 03:33:06 there's +VTD to query duration used in +VTS Sep 10 03:34:07 +VTD docs on STE say default = 0 Sep 10 03:34:13 0 -> Manufacturer specific, default 70ms Sep 10 03:34:15 the problem with sending the pauses through ATD is that the SIM wants us to send them after the call is connected (the first pause is meant as a wait-for-call-connected sign) Sep 10 03:34:37 I know Sep 10 03:34:38 ah, let's use 70ms then Sep 10 03:34:49 We basically have to do the entire logic in the core Sep 10 03:34:54 And guess on the DTMF duration Sep 10 03:35:09 Pekka has a related task to this Sep 10 03:35:20 But then ISI modems *actually* tell you wtf is going on Sep 10 03:35:27 that's not much problem because we can reuse the same code for SendDTMF and SetUpCall then Sep 10 03:36:00 Can you play with a few modems by setting the VTD duration to max Sep 10 03:36:08 maybe the logic should even be in the driver Sep 10 03:36:12 And see if VTS returns right away or only after the tone has been sent? Sep 10 03:36:27 And yeah, I'm leaning towards that as well Sep 10 03:36:58 i'll play with +VTS Sep 10 03:37:25 i took vacations until next wednesday though, so will do it after Sep 10 03:38:31 No prob Sep 10 03:39:13 so maybe the driver should do the waiting and call back when it is finished playing the tones Sep 10 03:39:24 that would also affect the dbus method Sep 10 03:41:59 yah, I'm actually fine with that too Sep 10 03:42:09 the pause part is still tricky Sep 10 03:51:47 zhenhua: So does your app actually do something? Sep 10 05:09:15 denkenz: it shows stk menu in QTextEdit...do what? Sep 10 05:09:35 denkenz: if you means make a voicecall, then it doesn't support it yet Sep 10 06:51:43 16:32 < denkenz> akiniemi: What is the patch 'Fix port number handling' trying to do? Sep 10 06:51:47 16:32 < denkenz> akiniemi: What is the patch 'Fix port number handling' trying to do? Sep 10 06:52:00 16:32 < denkenz> akiniemi: What is the patch 'Fix port number handling' trying to do? Sep 10 06:52:25 * akiniemi wonders what the heck just happened... Sep 10 06:52:35 denkenz: anyway, about ^ Sep 10 06:53:10 denkenz: all I know it screwed up port numbering when I tested my sms agent Sep 10 06:55:07 denkenz: that is, when the sender was using 16bit numbers, they got garbled Sep 10 07:06:19 denkenz: I got my Dell 5540 working. I did all stupid things you can do before doing it right. summary: the card is net locked and I need to add a pigtail. Sep 10 07:06:34 denkenz: propapbly it just works for you Sep 10 12:24:25 holtmann: there are issues with mbm and/or huawei? ;-o Sep 10 13:01:31 akiniemi: Yeah, the thought was to use bits 24-8 for 16 bit ports and bits 8-0 for 8 bit ports Sep 10 13:01:56 akiniemi: So the dispatcher wouldn't need another gboolean in there Sep 10 13:19:57 zhenhua: I actually see nothing when I startup your stkmenu Sep 10 13:20:19 All I get is: Sep 10 13:20:20 Registering type StkItem Sep 10 13:20:21 DBus Base Service: ":1.1734" Sep 10 14:43:44 hi Sep 10 15:33:40 Hi all... do you know if modem huawei EM770 from a Asus 10005HGO netbook is supported by ofono ? Sep 10 15:39:15 I try ofono 2.7 with a kernel 2.6.33 and I get no ConnectionManager interface in dbus, even after call "enter pin" with success Sep 10 15:39:43 I also have a option_instat_callback error -2 coming from the option module Sep 10 15:40:51 I try to backport usbserial and option from current kernel head, same result... really strange :/ Sep 10 15:46:16 We have 'some' version of the EM770 working Sep 10 15:46:27 But don't have that particular Netbook Sep 10 15:47:02 However, there are some race conditions present in the current modem drivers, so use of PINs is highly discouraged Sep 10 15:47:13 We will get those issues resolved, but it might take a few more releases Sep 10 15:47:25 Okay I see Sep 10 15:48:35 Thanks Sep 10 15:48:49 I will search for which version of EM770 is working Sep 10 15:49:00 And give a try maybe to a updated firmware Sep 10 15:51:42 Maybe compare also what's different between ofono and umtsmon who is working with the card Sep 10 15:58:06 The issue is simply that Huawei firmware sucks Sep 10 15:58:24 It doesn't tell oFono when it is 'ready' Sep 10 15:59:28 So we need to work around these issues, but nobody has found time yet Sep 10 17:34:41 balrog-k2n: Btw, it sounds like our stk text encoder does not handle empty responses Sep 10 18:54:25 denkenz: Is atgen and phonesim patches are both rejected due to whitespace errors? Sep 10 18:55:13 Jeevaka: As Denis mentioned the repository is pretty strict with whitespace damages. Please fix them up and re-send. Sep 10 19:00:39 I have set my git config file for reporting white space errors.its not reporting. Is there anything specific to be set to detect this errors? Sep 10 20:01:39 Jeevaka: for me it is a combination of vim syntax highlighting, git setup and practice Sep 10 20:02:20 Jeevaka: The atgen patch I'm still thinking about. We are actually planning to get rid of atgen completely, so I'm inclined to drop that patch Sep 10 20:27:55 Jeevaka: Still here? Sep 10 20:28:11 yes Sep 10 20:28:44 Lets talk about the driver changes patch Sep 10 20:28:50 ok Sep 10 20:29:04 + int msg_len = 0; Sep 10 20:29:04 + int dcs = -1; Sep 10 20:29:05 + unsigned char *coded_msg = NULL; Sep 10 20:29:22 Please don't initialize variables, it hides errors Sep 10 20:29:24 initialisation? Sep 10 20:29:40 oFono is using strict compiler flags that warn of uninitialized var use Sep 10 20:30:29 So, do I need to disable the compiler flag Sep 10 20:30:38 I mean in my local setup Sep 10 20:30:43 No, why are these necessary? Sep 10 20:31:50 I think initialisation was done to avoid compiler warnings Sep 10 20:32:49 Yeah I can see that now Sep 10 20:33:09 That code is a mess, this is why we disapprove of variable initialization Sep 10 20:33:27 ok Sep 10 20:34:08 Basically it should go something like: Sep 10 20:34:19 if (!msg || len < 4) Sep 10 20:34:21 return? Sep 10 20:34:32 status = isi_* Sep 10 20:34:44 if (msg[3] == 0 || .. ) { Sep 10 20:34:48 ofono_ussd_notify(); Sep 10 20:34:49 return; Sep 10 20:34:50 } Sep 10 20:35:32 ofono_ussd_notify(ussd, status, msg[1], msg[3], msg+4) Sep 10 20:36:04 Also, I'm not an isi expert, so you need to double check that casting const data to non-const is OK Sep 10 20:36:54 ok Sep 10 20:39:40 + unpacked_buf = unpack_7bit(pdu, len, 0, TRUE, max_chars, Sep 10 20:39:40 + &written, 0); Sep 10 20:39:46 Please use unpack_7bit_own_buf here Sep 10 20:39:56 You can trust the core to send you sensible data Sep 10 20:40:16 same thing here: Sep 10 20:40:17 + converted = encode_hex(pdu, len, 0); Sep 10 20:40:24 Should use encode_hex_own_buf Sep 10 20:40:46 The buf size is bounded to be max(160*2, 182) Sep 10 20:41:57 That should also keep the code simpler, you won't need to g_free everywhere Sep 10 20:42:07 in cusd_parse: Sep 10 20:42:39 If you can't parse the DCS from the GAtResult, set it to 0 Sep 10 20:42:40 Usage of the 2 addition buffer in stack Sep 10 20:42:57 is that ok? Sep 10 20:43:05 Actually just one Sep 10 20:43:12 buf[320] should be enough Sep 10 20:43:41 ok Sep 10 20:44:33 + if (charset == SMS_CHARSET_7BIT) { Sep 10 20:44:33 + if (data->charset == AT_UTIL_CHARSET_GSM) Sep 10 20:44:33 + msg_ptr = pack_7bit_own_buf((const guint8 *) content, Sep 10 20:44:34 + strlen(content), 0, TRUE, Sep 10 20:44:34 + &msg_len, 0, msg); Sep 10 20:44:47 This part needs to handle CHARSET_UTF8 as well Sep 10 20:44:53 Maybe even CHARSET_UCS2 Sep 10 20:45:35 specification doesn state the coded information Sep 10 20:45:48 There are modems that support this for sure Sep 10 20:45:51 e.g. the Freerunner Sep 10 20:46:35 Qtopia / FSO was hacked to deliver USSDs in UCS2, and it actually does it Sep 10 20:46:35 If the dcs is set to 7-bit, then the TA converts the received string as per the information available in Annex A 27.005 Sep 10 20:47:11 To be clear, DCS is set to 7 bit, but CSCS is set to UCS2 Sep 10 20:47:22 yes Sep 10 20:47:29 The Freerunner will report UCS2 chars Sep 10 20:47:34 Iok Sep 10 20:47:49 In that case, we atleast have one working modem which does that Sep 10 20:48:01 so we need to provide the conversion support Sep 10 20:49:02 Yeah, its a bizarre case, but since we're touching this part of the code anyway.... ;) Sep 10 20:49:04 since the specification, didn't specify what coding will be used if the dcs is 7-bit and cscs set to UCS2, i left it unhandled Sep 10 20:50:12 "If you can't parse the DCS from the GAtResult, set it to 0", is this in the at_cusd_parse? Sep 10 20:50:39 Yeah Sep 10 20:50:58 we are already setting it to 7-bit which is 0 Sep 10 20:51:20 if (g_at_result_iter_next_number(&iter, &dcs)) { Sep 10 20:51:20 - if (!cbs_dcs_decode(dcs, &udhi, NULL, &charset, Sep 10 20:51:20 - &compressed, NULL, &iso639)) Sep 10 20:51:20 - goto out; Sep 10 20:51:23 - Sep 10 20:51:23 - if (udhi || compressed || iso639) Sep 10 20:51:24 + if (!cbs_dcs_decode(dcs, NULL, NULL, &charset, Sep 10 20:51:24 + NULL, NULL, NULL)) Sep 10 20:51:24 goto out; Sep 10 20:51:24 } else Sep 10 20:51:25 charset = SMS_CHARSET_7BIT; Sep 10 20:51:31 So we don't actually set the DCS Sep 10 20:51:34 We set the charset Sep 10 20:51:39 oh ok Sep 10 20:51:54 Instead it should be something like Sep 10 20:52:04 if (g_at_result_iter_next_number(&iter, &dcs) == FALSE) Sep 10 20:52:09 dcs = 0 Sep 10 20:52:14 cbs_dcs_decode... Sep 10 20:52:40 In the core: Sep 10 20:52:41 + converted = convert_utf8_to_gsm(str, strlen(str), NULL, &written, 0); Sep 10 20:52:42 + if (!converted) Sep 10 20:52:42 + return __ofono_error_invalid_format(msg); Sep 10 20:52:42 + Sep 10 20:52:50 You have to make sure that written is less than 182 Sep 10 20:53:18 Otherwise even pack_own_buf is not safe Sep 10 20:53:36 ok Sep 10 20:53:41 + ussd->driver->request(ussd, dcs, packed, (int) num_packed, Sep 10 20:53:45 The cast there is not needed Sep 10 20:53:50 In general avoid casts like the plague Sep 10 20:53:55 ok Sep 10 20:54:11 Same comments to ussd_respond Sep 10 20:54:18 ok Sep 10 20:55:23 You might want to simply add ussd_encode funciton to smsutil that will do all of this for you Sep 10 20:55:55 We will be using in only 2 places Sep 10 20:56:26 having a separate function is the better option to reduce the code duplication Sep 10 20:57:00 Also remember it is easy to write unit tests for stuff in smsutil Sep 10 20:57:08 Not so easy to write unit tests against ussd.c Sep 10 20:57:51 I think that's it for my comments for that patch Sep 10 20:59:29 one more thing is that we are currently validating the USSD string to # at the end of the ussd string Sep 10 21:00:04 Is it the case always? Sep 10 21:01:36 For initial USSD requests that is what the spec tells us Sep 10 21:01:43 If the ussd is coming from the user, then it will have # Sep 10 21:01:44 For SIM requests we might need to skip that validation Sep 10 21:02:08 We are already skipping that validation Sep 10 21:02:37 Then it looks like we're correct Sep 10 21:02:42 Wanted to discuss, one more thing related to SIM Sep 10 21:02:55 sure Sep 10 21:02:55 do you have some time? Sep 10 21:03:10 One more comment: Sep 10 21:03:12 +enum ofono_ussd_failure { Sep 10 21:03:12 + OFONO_USSD_FAILURE_NONE, Sep 10 21:03:13 + OFONO_USSD_FAILURE_USER_TERMINATED, Sep 10 21:03:13 + OFONO_USSD_FAILURE_RETURN_ERROR, Sep 10 21:03:13 + OFONO_USSD_FAILURE_TIMED_OUT, Sep 10 21:03:13 +}; Sep 10 21:03:14 + Sep 10 21:03:21 Remove this enum, and use errno values instead Sep 10 21:03:31 e.g. USER_TERMINATED = -ECANCELED Sep 10 21:03:46 TIMED_OUT = -ETIMEDOUT Sep 10 21:03:52 ok Sep 10 21:03:52 RETURN_ERROR = -EINVAL Sep 10 21:04:08 See Andrew's send tone RFC patch Sep 10 21:04:11 He does something similar Sep 10 21:04:38 Currently, all the sat commands are sent with the A0****** Sep 10 21:05:13 Also for sim polling we are using the A0F200C0 Sep 10 21:05:54 first byte depends on the SIM application active Sep 10 21:06:32 If I remember correctly, A0 is for SIM application and 02 or 82 is for USIM application Sep 10 21:07:13 for example, if the current application is USIM and if we send a command with A0F200C0, then the SIM will respond with the class not supported Sep 10 21:07:54 I hope this is known Sep 10 21:07:59 Could be, we actually only enable sim-polling in phonesim Sep 10 21:08:14 All 'real-world' modems do the polling for us Sep 10 21:08:36 yep Sep 10 21:08:41 And phonesim is 2G only Sep 10 21:08:52 I don't think SIM Polling is described in 3GPP specs after 51.011 Sep 10 21:09:02 Do you know what spec describes this part for 3G? Sep 10 21:09:38 meaning SIM polling or about the class types? Sep 10 21:09:52 Well the 02/82 part Sep 10 21:10:04 That looks an awful lot like BER-TLV encoding from 102.221 Sep 10 21:13:14 ETSI TS 102 221 has detailed information this class, instruction and few more things Sep 10 21:14:10 Isn't the isimodem atleast gives the application chosen information? Sep 10 21:16:12 No idea, isimodem is a bit strange Sep 10 21:16:17 N900 has no support for STK in firmware Sep 10 21:16:51 And alot of AT modems don't even provide +CSIM access, only +CRSM Sep 10 21:17:25 thats because the polling and major logic resides in the modem side Sep 10 21:18:12 I know, and the majority of our operations are +CRSM based Sep 10 21:18:25 Only polling goes through CSIM, and that's not used on any 'proper' driver Sep 10 21:20:36 thats it from my side, thank you very much for your review comments Sep 10 21:21:19 sure, no prob ;) Sep 10 21:27:32 denkenz, yang_office: Is there any specific reason why we dont handle language notification proactive command, I dont see this in TODO list as well Sep 10 21:27:58 We can, I just haven't seen the point to so far Sep 10 21:28:06 Feel free to send a patch adding that to the TODO Sep 10 21:28:20 ok **** ENDING LOGGING AT Sat Sep 11 02:59:57 2010