**** BEGIN LOGGING AT Wed Jun 09 02:59:57 2010 Jun 09 06:42:25 wow, earthquake and tsunami warning service Jun 09 06:43:05 haven't heard about that one before Jun 09 13:53:12 denkenz: what do think about adding a new notify function to the core for updating the technolgy? Jun 09 14:02:08 my modem changes name everytime I plug it in: huawei0, huawei1 etc. is that on purpose? Jun 09 14:08:18 same here. after restarting ofono it starts at 0 again Jun 09 14:08:36 that confuses connman Jun 09 14:08:38 hmm Jun 09 14:08:49 wagi: thanks Jun 09 14:09:37 yeah: snprintf(path, sizeof(path), "/%s%d", type, next_modem_id); Jun 09 14:09:45 in ofono_modem_create() Jun 09 14:10:06 propably a static integer for enumerating them Jun 09 14:10:08 that's just the path though and should be a good way to ensure users don't rely on it Jun 09 14:10:51 but connman stores settings based on that id Jun 09 14:14:18 src/modem.c:ofono_modem_create() name: (nul Jun 09 14:14:20 l), type: huawei Jun 09 14:14:41 kvalo: That happens if the USB descriptors have no serial number. Jun 09 14:14:52 holtmann: aha! thanks Jun 09 14:15:26 crappy huawei Jun 09 14:15:35 I was working on sort of a fix where the udev plugin open the TTY and reads the serial number via AT command, then closes it again before actually creating the modem inside oFono. Jun 09 14:15:53 Huawei has a special AT command that gets you the serial number. I think it is ^SN. Jun 09 14:16:21 did I mention that I hate huawei? ;) Jun 09 14:16:40 wagi: Thought about it, don't like it Jun 09 14:16:52 in a way it was good that I bought the crappiest modem on the market, at least I get to learn about all the problems... Jun 09 14:18:05 kvalo: Btw. ConnMan should create its path not based on the modem path from oFono. Jun 09 14:18:18 It should create its path based on the IMSI alone. Jun 09 14:18:51 holtmann: yeah, that would be better Jun 09 14:18:55 kvalo: Look into ConnMan for fixing this. That is the first step here. Jun 09 14:19:10 sameo: Jun 09 14:19:11 17:18 < holtmann> kvalo: Btw. ConnMan should create its path not based on the modem path from oFono. Jun 09 14:19:15 17:18 < holtmann> It should create its path based on the IMSI alone. Jun 09 14:20:12 kvalo: That is inside the oFono plugin in ConnMan. Not really Samuel's problem. It was a clear hint that you should send a patch for it ;) Jun 09 14:20:13 holtmann: I can do it unless sameo wants to do it :) Jun 09 14:20:27 holtmann: hehe, I'll do it Jun 09 14:21:18 kvalo: yes, we should only be looking at the imsi, obviously. Jun 09 14:22:10 wagi: I still think this patch is too complicated, can't we set the tech directly in octi/owcti/ossysi updates? Jun 09 14:24:51 sameo: I'll come up with something and send to the list Jun 09 14:27:53 kvalo: awesome, thx a lot. Jun 09 14:41:20 denkenz: Not sure if you can get away without caching the state of the octi/ouwcti/ossysi values. Looking only at ossysi wont work. Jun 09 14:41:51 denkenz: in other words, I think we need some sort of state machine for this. Jun 09 14:42:50 wagi: Not quite sure I agree, we can rely on the order Jun 09 14:43:08 besides, OWCTI is useless Jun 09 14:43:11 denkenz: about the callback, do you want to solve this? Should I cache the status/lac/ci again? Jun 09 14:43:15 it reports the current bearer, not cell capability Jun 09 14:43:47 isn't that what the Technology property tells me? Jun 09 14:44:01 I'm not interessted in the Technologies property Jun 09 14:44:02 hah, depends on the modem Jun 09 14:44:19 The 3GPP spec defines CREG to report cell capability Jun 09 14:44:26 That is how Nokia modems work Jun 09 14:44:39 3GPP also defines a CPSB -> Current Packet Switched Bearer command Jun 09 14:44:46 That reports the actual bearer used Jun 09 14:45:04 Some modems do one but not the other Jun 09 14:45:07 and vice-versa Jun 09 14:45:23 oh, thanks for the clarification. Jun 09 14:45:44 Technology maps to CPSB? Jun 09 14:46:01 and without docs we're all just guessing as to what a particular modem does Jun 09 14:46:37 Today we map technology to cell capability Jun 09 14:47:15 okay, now I understand why you don't like my patches :) Jun 09 14:47:30 its not that at all Jun 09 14:47:45 Just this modem is acting 'different' Jun 09 14:47:51 I understood that technology is the current packet switched bearer Jun 09 14:48:25 btw, what does in this sense Technologies mean? Jun 09 14:48:51 wagi: Technologies is even more different, it is the technology types this operator supports Jun 09 14:49:02 wagi: E.g. some operators are 3G only, others are 2G only Jun 09 14:49:29 wagi: It helps you select a proper roaming partner overseas for instance Jun 09 14:49:56 okay Jun 09 14:50:32 akiniemi, pessi: Does ISI support packet switched bearer reporting? Jun 09 14:50:51 Then I missused the Technology property for my use case Jun 09 14:51:23 Everyone has, including 3GPP Jun 09 14:52:02 any idea how I could resolve this? :) Jun 09 14:52:09 adding a new property? Jun 09 14:52:22 CurrentTechnology? Jun 09 14:52:31 so I'm thinking we'll add a new property, either to context or data connection manager with the current bearer type Jun 09 14:53:05 For netreg, in the case of HSO, we just use OCTI & OSSYSI Jun 09 14:53:15 so you can get gsm gprs edge umts Jun 09 14:53:25 No hspa* ones Jun 09 14:53:43 okay Jun 09 14:53:48 Unless someone has better ideas Jun 09 14:56:33 okay for netreg I know how to do that Jun 09 14:57:07 how do I add this for data connection manager Jun 09 14:57:19 should I add callback again for OCTI & OSSYSI Jun 09 14:57:32 denkenz: Hold on. Netreg should only care about 2G vs 3G. For DCM we need the detailed edge, hspa etc. Jun 09 14:57:34 and additional for OUWCTI? Jun 09 14:58:12 In this case only OSSYSI is necessary for netreg Jun 09 14:58:21 We need more data on how the modems interact Jun 09 14:58:38 There are several ways this gets reported Jun 09 14:58:44 e.g. CREG/CGREG Jun 09 14:58:51 CPSB Jun 09 14:59:18 And then all the whacky vendor commands like *EPSB, *ERINFO, OCTI/OWCTI Jun 09 14:59:23 ^MODE, etc Jun 09 14:59:44 To me it looks like isi acts just like *ERINFO Jun 09 15:00:50 So my rough idea is that we should do cell capability on netreg Jun 09 15:01:11 and actual tech on dcm or context Jun 09 15:05:02 Sounds fine to me. Jun 09 15:05:21 righto, then I'll try to write something if nobody objects Jun 09 15:06:29 sure Jun 09 16:49:19 denkenz: We have to consider a new release. What is your pending queue? Jun 09 16:49:57 nothing at this point Jun 09 16:51:11 What about the STK patches from Andrew? Jun 09 16:51:28 And do we get this tech stuff sorted out. Jun 09 16:51:55 I'm still reviewing stk Jun 09 16:52:03 when do you want to do the release? Jun 09 16:52:15 and tech stuff requires more thought and input from Nokians Jun 09 16:52:18 Doesn't have to be today, but latest Friday morning. Jun 09 16:52:41 by then I can review the pending items on the list Jun 09 16:52:47 Sweet. Jun 09 16:53:06 I have to push a bit on having more regular releases. Otherwise we get this massive chunk release again. Jun 09 16:53:44 no problem for me, but we tend to have fully working codebase at all times Jun 09 16:53:56 I still wanna get the CBS stuff fixed. Since that needs to get testing. Jun 09 16:54:23 the one reported in the test report? Jun 09 16:57:24 My Qualcomm specific crap. Jun 09 16:57:48 I am still debating to start with qcmodem driver. Jun 09 16:58:33 that one can be quirked Jun 09 16:59:20 Can be of course. I will look into this. And when I am back in Europe I should have networks that support CBS. And hopefully get some of them then. Jun 09 18:16:52 yang_office: Can you work on getting the 3GPP specific proactive command parsers finished up? Jun 09 18:17:01 yang_office: We're missing Send SS & Send USSD at least Jun 09 18:17:13 31.111 Jun 09 21:23:25 balrog-k1n: this really needs to go away: Jun 09 21:23:26 const char *imei; Jun 09 21:23:28 struct stk_network_measurement_results { Jun 09 21:23:29 struct stk_common_byte_array nmr; Jun 09 21:23:31 struct stk_bcch_ch_list { Jun 09 21:23:32 const short *channels; Jun 09 21:23:34 int length; Jun 09 21:23:35 } bcch_ch_list; Jun 09 21:23:37 } nmr; Jun 09 21:23:38 struct sms_scts datetime; Jun 09 21:23:40 const char *language; Jun 09 21:23:45 things like const char *imei, const char language, not good Jun 09 22:10:42 denkenz: If I would look into the PIN retry information? Where do you want that. Jun 09 22:11:04 Are we going to quirk this into the SIM atom driver? Jun 09 22:15:15 holtmann: good question Jun 09 22:15:30 holtmann: Probably that would be an extra query Jun 09 22:15:47 e.g. query_pin_counts Jun 09 22:20:29 Something like that. I wanna do this for Ericsson and Huawei at least. Jun 09 22:21:04 That's what I would do, then oFono can query pin_counts after pin_query Jun 09 22:23:22 So we quirk it. Jun 09 22:24:06 sounds like it Jun 09 23:11:10 denkenz: ok, i can change them to constant sized buffers Jun 09 23:11:40 i used pointers because that's what the existing structs used, for proactive commands Jun 09 23:12:19 balrog-k1n: Except they're not const and are freed by stk_command_free Jun 09 23:13:13 i don't free them because i don't allocate them :) Jun 09 23:14:56 the rationale is, when you want to submit an stk_envelope or stk_response struct to stkutil.c, and you have all the contents at hand, you just need to set a pointer Jun 09 23:15:00 no need to memcpy Jun 09 23:15:46 there's a useless memcpy in __ofono_cbs_sim_download now Jun 09 23:16:57 These are not really critical path though Jun 09 23:18:01 still ugly Jun 09 23:18:18 also, can't you play const struct trick there? Jun 09 23:18:45 in __ofono_cbs_sim_download? Jun 09 23:18:53 ah no, you can't Jun 09 23:20:12 Then perhaps we should do something like: Jun 09 23:21:06 const unsigned char *stk_cbs_pp_envelope_pdu(const struct cbs *page); Jun 09 23:21:19 maybe these weird structures are just wrong Jun 09 23:22:16 i proposed just using a function for each envelope, but now i see structs give you more flexibility, Jun 09 23:22:40 passing a pointer to a struct is like passing a couple of parameters, but you can use unions etc Jun 09 23:22:48 there's no reason why we can't have both for critical path items Jun 09 23:22:58 however, const inside those structures won't work Jun 09 23:23:04 especially if we need to parse envelopes Jun 09 23:25:17 balrog-k1n: While you're here, I'm totally lost in patch 16 For unitialised stk_location_info emit no data object Jun 09 23:26:02 denkenz: the object is optional in some envelopes or responses Jun 09 23:26:44 I don't see what your patch accomplishes though Jun 09 23:27:14 it changes the meaning of the uninitialised stk_location_info (all zeros), Jun 09 23:27:20 from empty data object to no object Jun 09 23:27:47 yang said on the list it was desirable that the meaning of an unitialised struct is no object Jun 09 23:29:19 err, but you're still checking the mcc everywhere Jun 09 23:30:12 must be getting late in the day, I just don't see the utility Jun 09 23:30:21 what do you mean? Jun 09 23:30:35 this is for cases where you memset your entire envelope or response struct to zero, Jun 09 23:30:49 and then set some number of its fields to the values you want Jun 09 23:31:20 and then fields you don't touch, will mean no data objects will be emitted when you pass the stk_response / stk_envelope to the pdu_from_xxx function Jun 09 23:32:08 it can be seen how it's used in the unit tests Jun 09 23:32:11 I don't see how this is happening Jun 09 23:32:26 since in the for loop you always emit an empty object Jun 09 23:33:16 ok the for loop is a little tricky, Jun 09 23:33:49 in the case of the provide local info the location info object is not optional, Jun 09 23:33:54 but it can be empty Jun 09 23:34:27 so in this case we override the meaning of an uninitialised element in the list Jun 09 23:34:35 we can't just skip it Jun 09 23:35:59 sounds complicated Jun 09 23:36:15 i realise it's not the most readable piece of code, but you have to read the specs anyway to interpret it, Jun 09 23:36:34 and imho it makes for the easiest api for the user of the whole pdu_from_xxx functions Jun 09 23:36:50 sounds like you're abusing the encoder function for the benefit of something else Jun 09 23:36:58 they don't have to indicate that no location is given by setting something like location.no_info = TRUE Jun 09 23:38:13 see event_download_location_status_data_111 in the Event Download tests patch Jun 09 23:38:40 in this case the location_info field remains uninitialised Jun 09 23:40:10 if you had initialised it with some mmc/mnc, pdu_from_envelope would include that data object Jun 09 23:42:09 I'm seriously lost Jun 09 23:42:16 Why aren't we using a GSList here? Jun 09 23:43:10 we could, but arrays are way simpler to use, more readable etc Jun 09 23:43:27 certainly not the more readable part ;) Jun 09 23:43:34 i realise that is subjective Jun 09 23:43:48 but i can't know what is readable to you :) Jun 09 23:44:31 you can't have a nice initialiser for a GSList for example Jun 09 23:44:38 whlie arrays are part of the language Jun 09 23:44:43 honestly, I'm lost right now in this one Jun 09 23:45:45 There must be a nicer way of doing this than array of techs, followed by array of location infos Jun 09 23:46:09 And I still don't see how you breaking it up into 2 functions does *anything* Jun 09 23:46:14 it could be a single array / list / whatever Jun 09 23:46:27 which 2 functions? Jun 09 23:46:35 I've re-read patch 16 about 6 times now Jun 09 23:46:48 It doesn't seem to me you're changing the behavior at all Jun 09 23:47:21 i don't really care what the struct will look like, if you can propose what it should look i'll change it Jun 09 23:49:36 ok, let me try it this way Jun 09 23:49:49 if I skip patch 16, what will happen ? Jun 09 23:50:15 Event Download tests will fail, Jun 09 23:50:33 and you'll have to add a new bool field to that struct to make them work i think Jun 09 23:52:49 - for (i = 0; i < info->location_infos.access_techs.length; i++) Jun 09 23:52:51 + for (i = 0; i < info->location_infos.access_techs.length; i++) { Jun 09 23:52:52 + dataobj_writer location = build_dataobj_location_info; Jun 09 23:52:54 + /* Jun 09 23:52:55 + * "If no location information is available for an Jun 09 23:52:57 + * access technology, the respective data object Jun 09 23:52:58 + * shall have length zero." Jun 09 23:53:00 + */ Jun 09 23:53:01 + if (info->location_infos.locations[i].mcc[0] == '\0') Jun 09 23:53:03 + location = build_empty_dataobj_location_info; Jun 09 23:53:04 + Jun 09 23:53:06 if (build_dataobj(builder, Jun 09 23:53:07 - build_dataobj_location_info, Jun 09 23:53:09 + location, Jun 09 23:53:10 so if mcc is NULL, we emit an empty object Jun 09 23:53:33 In the previous code, if MCC is NULL, we emitted an empty object Jun 09 23:53:34 in Provide Local Info, yes, we don't want to change its behavior Jun 09 23:53:40 what is different here? Jun 09 23:53:57 it was already correct, no need to change how Provide Local Info works Jun 09 23:55:17 we change the behaviour for the other responses/envelope which the patch does not change Jun 09 23:55:45 err does not touch.. Jun 09 23:56:14 ok, so I'm not insane (yet) Jun 09 23:56:16 :) Jun 09 23:56:38 yeah, it's tricky Jun 09 23:56:53 the idea was for the api to be simple, by adding complexity inside stkutil.c Jun 09 23:59:13 Ok, I'm about to shoot myself Jun 09 23:59:24 102.223 says to look up the tech specific spec for Location Status Jun 09 23:59:31 31.111 tells to look in 102.223 Jun 10 00:00:08 heh Jun 10 00:00:33 24.008 and 24.301 have the actual definitions for UTRAN, E-UTRAN and what not Jun 10 00:03:44 ok I think I see it now Jun 10 00:05:50 Basically you're saying that for provide local info, the location object is mandatory Jun 10 00:06:04 But for others, its optional Jun 10 00:06:13 right? Jun 10 00:06:32 yes, not all others, for Event Download yes Jun 10 00:06:50 for Provide Local Info they're mandatory because the indices on the list matter Jun 10 00:08:38 ok, a comment along those lines would have been nice Jun 10 00:08:56 I was staring at that patch and not understanding the point :) Jun 10 00:12:37 maybe each of the structs defining the data objects should have a comment on how to use them... but i image the tests make up for it Jun 10 00:28:33 For the most part they're fine, I just tend not to peek-ahead on patches Jun 10 00:28:50 so I like to have comment / context if something is not self-explanatory Jun 10 01:43:30 denkenz: So I am lazy with the CBS fix to not check the result of AT+CSCB=1, but that should be fine. Stuff is pushed now. Jun 10 01:47:13 holtmann: Looks good to me Jun 10 02:39:20 denkenz: I missed that spec. Will send the patches for them. **** ENDING LOGGING AT Thu Jun 10 02:59:57 2010