**** BEGIN LOGGING AT Fri Dec 10 02:59:57 2010 Dec 10 04:57:29 hello, is ofono log saved somewhere when running ofono in background? or any method to show the logs without restart it?? Dec 10 05:16:14 it goes t osyslog Dec 10 07:20:07 courmisch: where is the osyslog generaly? I cannot find it in device side. Dec 10 09:51:42 chenmin: the standard syslog.. e.g. at /var/log/syslog .. check /etc/syslog.conf on your system Dec 10 10:12:24 denkenz: re. where can i drop a patch for huawei em770? Dec 10 10:12:46 emdete: The mailing list? Dec 10 10:13:02 can i post if not subscribed? Dec 10 10:13:19 nope Dec 10 10:13:25 spam guard Dec 10 10:14:36 ...? Dec 10 10:15:37 so where can i send it then? Dec 10 10:16:15 the page http://ofono.org/community looks strange - is the html intended? Dec 10 10:25:01 denkenz: ? Dec 10 10:25:38 ofono@ofono.org Dec 10 10:26:23 http://pyneo.org/downloads/0001-set-huawei-em770-modem-device-to-01-to-free-up-00.patch Dec 10 10:26:26 http://pyneo.org/downloads/0002-fake-a-sim-inserted-status.patch Dec 10 10:26:44 this ain't going to work this way Dec 10 10:26:47 post it to the ML Dec 10 10:27:33 http://lists.ofono.org/listinfo/ofono Dec 10 10:28:18 11:12 denkenz> nope Dec 10 10:28:32 just subscribe Dec 10 10:28:43 but seriously, I'm not looking at it unless its on the ML Dec 10 10:36:29 okay, i wont subscribe. sorry. Dec 10 12:18:48 denkenz:ping Dec 10 13:19:52 denkenz: should i always display the retry counter property or only when PinRequired is set? Dec 10 13:20:20 i.e. when it's not 'none' Dec 10 15:08:36 demarchi: I think doing it always is fine Dec 10 15:09:28 demarchi: the pin can be changed even when the PIN is not required Dec 10 15:09:35 so the pin retry counter needs to be available Dec 10 15:43:00 denkenz: ok, thanks Dec 10 16:18:16 balrog-k2n: ---> Dec 10 16:18:18 ERROR:unit/test-stkutil.c:20898:test_envelope_encoding: assertion failed: (memcmp(pdu, test->pdu, pdu_len) == 0) Dec 10 16:27:59 * balrog-k2n updates Dec 10 16:41:22 denkenz, yang_office: the problem starts with the timezone encoding change, perhaps the unit test hasn't been updated, i'll check Dec 10 16:41:35 although the error msg is slightly different for me Dec 10 16:44:19 balrog-k2n: Are you fine with Guillaume's null text string fix? Dec 10 16:46:37 denkenz: yep, although the move of comprehension_tlv_iter_get_data isn't strictly necessary Dec 10 16:46:44 but it's fine Dec 10 16:47:42 Ok, I just pushed 4 fixes Dec 10 16:47:53 Can you review and tell me if I screwed up or missed something Dec 10 16:49:47 the kernel.org git seems to lag very often Dec 10 16:50:50 nod, no hurry Dec 10 16:51:22 have you fixed the SMS-PP envelope unit test too? Dec 10 16:53:26 yeah Dec 10 16:53:37 but check them as well Dec 10 17:03:22 balrog-k2n: And are you fine with the alpha id patch? Dec 10 17:14:44 denkenz: where's the alpha id patch? Dec 10 17:15:15 denkenz: iirc the set up idle mode text command can send a null text to unset the previously set one, like with the main menu setup Dec 10 17:15:46 [PATCH] stk: fix issue to avoid null pointer for alpha_id Dec 10 17:16:23 so this is the thing, we now do this: Dec 10 17:16:30 Text missing -> NULL Dec 10 17:16:37 text present with len = 0 -> "" Dec 10 17:16:44 text present with len > 0 -> "string" Dec 10 17:17:35 denkenz: ah yes, the alpha id patch is okay too (i had looked at it and deleted apparently) Dec 10 17:18:07 ok I will apply that one as well Dec 10 17:19:28 So do you still think there's a problem with setup idle mode text? Dec 10 17:20:23 but won't handle_command_set_idle_text return _NOT_UNDERSTOOD if the text is NULL? Dec 10 17:21:05 text is mandatory Dec 10 17:21:10 so it can never be null, right? Dec 10 17:22:36 oh perhaps, i guess that was my misunderstanding Dec 10 17:23:44 can you double check? I'd like to be extra paranoid when changing this Dec 10 17:24:30 yeah, i'm trying to see if every allowed scenario is handled :) Dec 10 17:26:10 so now i'm actually unsure if guillaume's patch was ok, since both a null text object and a "" return "" in parse_dataobj_text Dec 10 17:26:53 and they potentially have different meanings for Set-up Idle Mode Text although the difference for us is not important Dec 10 17:27:34 i.e. null text object removes the idle text, while "" sets the text to "" Dec 10 17:28:06 denkenz, balrog-k2n: can i interfere? Dec 10 17:28:16 Jeevaka: sure Dec 10 17:28:31 i think help to understand this is welcome :) Dec 10 17:29:20 I hope the discussion is about the fix provided for crash seen with null text object Dec 10 17:31:21 denkenz: but your patch is definitely fine because the behaviour of the dbus property is unchanged Dec 10 17:33:40 if the text string is provided with length 0, then incase of setup idle mode text it is meant for removal Dec 10 17:35:19 Jeevaka: only if the TLV length is zero, right? Dec 10 17:35:33 not if there's the dcs followed by zero characters Dec 10 17:36:41 dcs is included in the length calculation Dec 10 17:38:04 e.g: if the text string is "Idle text", then the length will be 10 Dec 10 17:38:16 which includes strlen + dcs byte Dec 10 17:41:27 Jeevaka: what i mean, is that according to 102.223, if text tlv consists of the Tag, the Length (1) and the DCS then this doesn't count as removal of the idle mode text Dec 10 17:41:32 it counts as setting it to "" Dec 10 17:41:54 but if the tlv consists of just the tag and the length (0), that counts as removal Dec 10 17:42:03 text of len == 1 is not valid Dec 10 17:42:08 see parse_dataobj_text Dec 10 17:42:53 ok, spec is misleading Dec 10 17:43:21 as per spec, if the text len = 0, then it means the removal of the idle mode text Dec 10 17:43:36 with one exception Dec 10 17:43:58 If the text len = 0 and there is no icon, then it means removal of the idle mode text Dec 10 17:44:24 if the text len = 0 but if there is icon tlv, then it means empty text string Dec 10 17:46:02 denkenz: true, but ts102223 8.15 doesn't have a basis for this Dec 10 17:46:53 there is no empty string case Dec 10 17:47:20 If the text string is provided with len = 0, then it means removal Dec 10 17:47:23 dunno, it says 'A null text string shall be coded with Length = '00', and no Value part.' Dec 10 17:47:44 so to me len = 1 is invalid Dec 10 17:47:58 yes agree with denkenz Dec 10 17:48:38 balrog-k2n, denkenz: null text string = removal of idle mode text Dec 10 17:48:39 that would mean that "" and null text are the same thing (maybe i missed where this is stated) Dec 10 17:49:07 now, the question is where did you get this empty string case valid info? Dec 10 17:49:12 these guys confused null and empty Dec 10 17:49:26 because the Text dataobj was meant to always be mandatory Dec 10 17:49:37 but later the spec got extended with text being optional Dec 10 17:50:00 so I think text not present -> null, text present, len = 0 -> empty Dec 10 17:50:03 makes sense Dec 10 17:50:39 well, i don't see any basis for that, but i can accept this interpretation Dec 10 17:51:13 oh I doubt there's explicit basis Dec 10 17:51:16 text not present = null = no text data object. do you mean this? Dec 10 17:51:17 to me it looks like the spec allows a null text object (len = 0), an empty string (len = 1) etc Dec 10 17:51:26 which is why we interpreted len == 0 as NULL earlier Dec 10 17:51:44 jeevaka: yes Dec 10 17:52:27 ok, now coming on to the fix. why we need to allocate? cant we simply use *text=""? Dec 10 17:52:40 no, we have to g_free the text at some point Dec 10 17:53:57 hmm i don't see why we treat len == 1 as error in parse_dataobj_text, though Dec 10 17:54:16 if anything let's treat it same as null text Dec 10 17:54:51 lets say len == 1 as error Dec 10 17:55:16 we can say that but card manufacturers may don't care :) Dec 10 17:55:22 s/may// Dec 10 17:55:31 you never know they might add a text case len==1 as one of the error confirmation case ;) Dec 10 17:56:41 len of 1 with no text makes no sense to me Dec 10 17:57:16 yes, so thats an error which we are already handling it Dec 10 17:57:17 to me it is the equivalent of "" Dec 10 17:59:31 so if we interpret len == 1 as valid, then this fix is wrong Dec 10 18:00:40 if the len == 1 check is removed then everything is fine, right? Dec 10 18:03:07 hm, in theory yes Dec 10 18:03:13 the len==1 check is inconsistent with build_dataobj_text, too Dec 10 18:03:28 but then its still wrong according to your interpretation of null/empty Dec 10 18:03:59 because both NULL passed to build_dataobj_text gets decoded as "" by parse_dataobj_text, and "" passed to build_dataobj_text returns an error in parse_dataobj_text Dec 10 18:04:49 denkenz: if we treat "no idle text" and "" the same on the dbus interface then it makes no difference Dec 10 18:05:51 text->text == NULL we don't write anything Dec 10 18:06:37 oh, right Dec 10 18:07:30 but yes, we don't handle empty strings properly Dec 10 18:07:54 but then all unit tests pass, what do they have to say about this? Dec 10 18:08:21 i think we can be neutral / manufacturer interpretation tolerant by just treating len==0 and len==1 the same Dec 10 18:08:43 because the spec is not clear and i'm sure there are different interpretations Dec 10 18:09:14 can you check TERMINAL RESPONSE: GET INPUT 1.9.1A Dec 10 18:09:24 what does empty get written out as? Dec 10 18:11:03 test case in test-stkutil.c sets .text to "", and it gets written as the DCS byte alone Dec 10 18:11:32 that's what I thought as well Dec 10 18:11:39 the test case actually allows both versions Dec 10 18:11:46 DCS alone or len==0 Dec 10 18:11:57 so our parse text function is wrong Dec 10 18:12:23 so we're good if we do this: Dec 10 18:12:24 - /* DCS followed by some text, cannot be 1 */ Dec 10 18:12:25 - if (len == 1) Dec 10 18:12:25 - return FALSE; Dec 10 18:12:25 - Dec 10 18:12:28 ? Dec 10 18:12:41 yes, i think that would fix it Dec 10 18:13:22 or at least not break anything that is working so far, and possibly make some manufacturer's cards not be rejected Dec 10 18:15:00 ok, so I pushed this fix Dec 10 18:15:05 the unit tests still pass Dec 10 18:15:19 but have another sanity check / think about it Dec 10 18:24:14 denkenz: any comments on cfis patch? Dec 10 18:29:21 are you sure we can't call sim_set_cf_indicator in set_new_cond_list? Dec 10 18:33:55 I forgot to check it Dec 10 18:34:32 we can call. I see your point calling it from set_new_cond_list will reduce number or lines of code Dec 10 18:36:01 ok, if we can do that then I prefer that Dec 10 18:38:38 any other comments? Dec 10 18:44:18 Do you want me to send only that patch or the whole set? Dec 10 18:48:15 you know how this works now ;) Dec 10 18:48:42 a full v4 set please Dec 10 18:49:02 the rest of the patches look fine Dec 10 18:49:08 ok Dec 10 18:50:18 by the way, as per the specification, 3g session shall not start if EFust read is not success Dec 10 18:51:32 hm, interesting, but we must still account for the case where the modem fails to read EFust Dec 10 18:51:48 e.g. firmware not supporting that operation Dec 10 18:52:10 but yeah, I think it is a good idea to check EFust before reading most files Dec 10 18:52:18 that way our start time is even better Dec 10 18:53:02 ok Dec 10 18:57:37 patch for cfis sent Dec 10 19:02:59 ok, let me see if I can look at it after dinner Dec 10 19:03:05 ok Dec 10 19:26:47 holtmann: denkenz: working on the gps atom and I have a question.. what do you think is better for the property name? enabled or powered?.. gprs atom uses "Powered" for example. And I also see that ctm uses Enabled **** ENDING LOGGING AT Sat Dec 11 02:59:57 2010