**** BEGIN LOGGING AT Fri Jul 30 02:59:57 2010
Jul 30 16:39:42 <mikeleib> denkenz: ping!
Jul 30 16:39:49 <denkenz> pong
Jul 30 16:39:51 <mikeleib> w00t
Jul 30 16:40:07 * mikeleib digs up question to ask denkenz 
Jul 30 16:40:53 <mikeleib> I'm writing a settings app for telephony for handset
Jul 30 16:41:02 <mikeleib> essentially, it sets some properties on ofono
Jul 30 16:41:20 <mikeleib> things like setting up call forwarding, etc
Jul 30 16:41:34 <mikeleib> however, I also have requirements to have settings for:
Jul 30 16:41:46 <mikeleib>   reject incoming calls based on a list of #'s
Jul 30 16:41:51 <mikeleib>   reject calls with no callerID
Jul 30 16:42:09 <mikeleib> I didn't see relevant ofono properties for that
Jul 30 16:42:34 <mikeleib> is that something that I overlooked, could be added to ofono, or could not be added to ofono?
Jul 30 16:43:25 <jprvita> denkenz: I've done the tests you've suggested, but no success :(
Jul 30 16:43:58 <jprvita> bisecting tells me the problem started on this commit: 6f4b3c31fdcf6a9991062d232f435310e5f3155e huawei: detect possible secondary device
Jul 30 16:44:06 <jprvita> kvalo: ^
Jul 30 16:45:10 <jprvita> if you guys think this is a regression that should be fixed, I'm more than happy to help testing / debugging 
Jul 30 16:45:16 <denkenz> mikeleib: I think I know where the incoming call rejection stuff is coming from
Jul 30 16:47:25 <denkenz> jprvita: Hmm, the detection patch shouldn't do anything
Jul 30 16:52:43 <jprvita> denkenz: is there something else I could do to try to isolate the problem?
Jul 30 16:55:48 <denkenz> jprvita: Sec, lemme look at that commit
Jul 30 16:56:14 <jprvita> ok, no hurry 
Jul 30 16:57:00 <denkenz> Ok, its highly doubtful that commit does anything
Jul 30 16:57:15 <denkenz> The commit responsible is the one that waits for the SIMST status to change
Jul 30 16:57:28 <denkenz> Have you tried marking the SIM as inserted manually?
Jul 30 17:01:16 <jprvita> yes, both on the initialization of the structure (data->sim_state = 1; on huawei_enable()) and on the notify_sim_state() function
Jul 30 17:02:06 <jprvita> I've tried this both with a E220 and a E156C
Jul 30 17:04:29 <denkenz> Hmm, lemme see
Jul 30 17:06:01 <denkenz> jprvita: So if you change sysinfo_cb to not bother parsing but calling ofono_sim_inserted_notify(TRUE)
Jul 30 17:06:04 <denkenz> Does it work?
Jul 30 17:09:05 <jprvita> I guess I did the same, a bit different...  I'm trying this way
Jul 30 17:11:51 <jprvita> denkenz: ok, now it does :) I guess i've only changed the data structure :/
Jul 30 17:12:18 <denkenz> Yeah, so basically we need to figure out why your firmware doesn't send SIMST
Jul 30 17:12:31 <jprvita> btw, E156C has much more interfaces supported :)
Jul 30 17:12:32 <denkenz> Can you play with this modem in minicom?
Jul 30 17:13:00 <denkenz> Try sending a CFUN=1 and resending SYSINFO? until you see the sim state change
Jul 30 17:13:31 <denkenz> E156C might be one of those EM770 based ones with voice
Jul 30 17:13:47 <jprvita> so I just type AT+CFUN=1 on minicom?
Jul 30 17:14:14 <denkenz> Yeah, shut down the modem the same way oFono does (CFUN=0 I think?)
Jul 30 17:14:21 <denkenz> and then send AT+CFUN=1
Jul 30 17:14:34 <denkenz> Then send SYSINFO, see whether it changes after x seconds
Jul 30 17:14:37 <balrog-k1n> whoa i built ofono on an ARM machine without disabling gisi and it didn't complain
Jul 30 17:15:12 <denkenz> Why is this surprising? I would have thought Nokia guys do it all the time ;)
Jul 30 17:15:35 <jprvita> hum, I have both ttyUSB0 and ttyUSB1, connected to ttyUSB0 and can't type anything..  do I need any special config on minicom?
Jul 30 17:15:45 <jprvita> like flow control or so
Jul 30 17:15:57 <balrog-k1n> last time i heard everyone blaming someone else for the build failures on ARM and nobody wanting to fix it :)
Jul 30 17:16:35 <jprvita> hum, nevermind
Jul 30 17:16:42 <jprvita> had ofono running at the same time
Jul 30 17:17:08 <denkenz> balrog-k1n: I think that was a really long time ago
Jul 30 17:24:48 <jprvita> AT^SYSINFO
Jul 30 17:24:48 <jprvita> ^SYSINFO:1,0,0,5,4,,4
Jul 30 17:24:48 <jprvita> OK
Jul 30 17:24:51 <jprvita> denkenz: ^
Jul 30 17:25:49 <denkenz> See, your firmware is telling us that sim is invalid
Jul 30 17:26:32 <denkenz> Are you sure this modem / sim is working?
Jul 30 17:26:37 <jprvita> is this 5 telling us this?
Jul 30 17:27:03 <denkenz> 1 -> service status : Restricted service
Jul 30 17:27:09 <jprvita> last time I've really used it was more about a year ago
Jul 30 17:27:13 <denkenz> 0: service domain: No service
Jul 30 17:27:30 <denkenz> 0 -> Roam Status: Non Roaming State
Jul 30 17:27:36 <jprvita> let'me try another sim
Jul 30 17:27:40 <denkenz> 5 -> System Mode: WCDMA mode
Jul 30 17:27:55 <denkenz> 4 -> Sim State: USIM is invalid in case of Either PS or CS
Jul 30 17:31:02 <jprvita> ok, other sim gives me this: ^SYSINFO:2,1,0,5,3,,4
Jul 30 17:31:51 <jprvita> this one I'm sure it can register on the network with ofono 0.16
Jul 30 17:32:36 <jprvita> also, manually forcing inserted state makes it register on the net too
Jul 30 17:32:50 <denkenz> That one is telling us its not valid in case of PS
Jul 30 17:33:39 <jprvita> what's PS? (guess is time to start to look at gsm specs)
Jul 30 17:33:55 <denkenz> PS = Packet Switched, e.g. your data connection
Jul 30 17:34:10 <denkenz> So basically that SIM is voice-only, about the only thing you can do with it is SMS
Jul 30 17:34:25 <jprvita> yes, this sim is voice-only
Jul 30 17:34:43 <denkenz> Then you need to modify the huawei logic to recognize such sims
Jul 30 17:35:05 <jprvita> hum, I do have a data and voice sim, letme see
Jul 30 17:35:34 <denkenz> Since Huawei is primarily a data modem, it's questionable whether voice-only SIMs are a good idea ;)
Jul 30 17:35:45 * jprvita starts to disassembly his personal cell phone
Jul 30 17:36:30 <jprvita> when I did sms tests i've used the E220
Jul 30 17:37:38 <denkenz> Sure, just that Huawei plugin is looking for full valid sims right now
Jul 30 17:38:03 <denkenz> And the huawei firmware never sends us a SIMST in the invalid case
Jul 30 17:38:35 <denkenz> Hence the regression ;)
Jul 30 17:40:33 <jprvita> weird..  with this sim the modem keeps getting connected and disconnected
Jul 30 17:41:12 <jprvita> but I've got the sysinfo answer from ofono: Pcui:< \r\n^SYSINFO:2,3,0,5,1,,4\r\n\r\nOK\r\n
Jul 30 17:43:18 <jprvita> nice, re-plugging it in made it stop going crazy
Jul 30 17:43:25 <jprvita> AT^SYSINFO
Jul 30 17:43:26 <jprvita> ^SYSINFO:2,3,0,5,1,,4
Jul 30 17:46:04 <jprvita> denkenz: hey, E156C seems to be working nice with ofono now 
Jul 30 17:46:14 <denkenz> There you go
Jul 30 17:46:29 <denkenz> So we can probably hack in support for your weird SIM
Jul 30 17:46:41 <denkenz> We'd just need to poll SYSINFO a few times / seconds
Jul 30 17:46:52 <jprvita> cool
Jul 30 17:46:54 <denkenz> If we determine its voice only SIM, then we should never initialize gprs
Jul 30 17:47:00 <jprvita> I'll also try with E220
Jul 30 17:47:10 <denkenz> Feel free to attempt it if you want :)
Jul 30 17:47:27 <jprvita> the more devices tested we have, the better, no?]
Jul 30 17:47:34 <denkenz> Yep
Jul 30 17:48:03 <jprvita> since my cellphone is already apart, it's O(1) to do this additional test ;)
Jul 30 17:48:37 <denkenz> balrog-k1n: Does phonesim go back to the main menu after a display text?
Jul 30 18:08:21 <jprvita> from E220 with voice-and-data sim I get ^SYSINFO:1,0,1,5,255,1,4
Jul 30 18:08:36 <jprvita> but IIRC this modem is operator-locked
Jul 30 18:09:55 <jprvita> denkenz: where can I find the specs or other docs to refer for the AT codes and all this stuff?
Jul 30 18:10:21 <denkenz> Most of it is in 3GPP 27.007
Jul 30 18:10:30 <denkenz> The Huawei specific crap you have to ask me
Jul 30 18:10:34 <denkenz> 255 means SIM Invalid
Jul 30 18:11:02 <denkenz> Rather, 255 -> "USIM Card not existent"
Jul 30 18:11:26 <jprvita> ok
Jul 30 18:12:06 <jprvita> so, which approach do you think is better to support voice-only sims?
Jul 30 18:12:35 <balrog-k1n> denkenz: i've not tried phonesim since the api was added.. it's possible that it doesn't send any kind of "end session"
Jul 30 18:12:35 <jprvita> and also, is this desirable or have any priority for ofono? (it seems to make sense imo)
Jul 30 18:13:07 <balrog-k1n> there was some at code *TSTE that meant session end but i don't remember whether that was a notification or a command
Jul 30 18:14:08 <denkenz> jprvita: Priority is definitely not High, but certainly something we can add
Jul 30 18:15:14 * balrog-k1n will bbl
Jul 30 18:27:12 <jprvita> denkenz: I can spend some time on adding this support, but I might need some help to better understand the problem 
Jul 30 18:27:26 <denkenz> no worries
Jul 30 18:29:21 <jprvita> I've tried to add a g_timeout for g_at_chat_send(data->pcui, "AT^SYSINFO", sysinfo_prefix, sysinfo_cb, modem, NULL) without success 
Jul 30 18:29:27 <jprvita> 1s timetou
Jul 30 18:29:35 <jprvita> timeout
Jul 30 18:30:25 <jprvita> what's the difference of polling SYSINFO more than once?
Jul 30 18:30:50 <jprvita> is it likely to change on some modem/sim?
Jul 30 18:50:20 <denkenz> jprvita: Some modems take a while to initialize the SIM on cold boot
Jul 30 18:50:41 <denkenz> jprvita: It might take 1-5 seconds for them to do that
Jul 30 18:50:46 <jprvita> I see
Jul 30 18:51:20 <jprvita> is SYSINFO one of the huawei specific crap you said before?
Jul 30 18:51:31 <denkenz> Yep
Jul 30 18:51:35 <jprvita> I can't find reference for it on 27.007
Jul 30 18:52:00 <denkenz> I have the docs, but I can't share them
Jul 30 18:52:53 <jprvita> damn NDAs
Jul 30 18:53:45 <denkenz> Yep, so I can tell you what stuff means, just can't give you the whole doc ;)
Jul 30 19:01:49 <jprvita> :w
Jul 30 22:20:54 <denkenz> holtmann, balrog-k1n: I pushed the cleaned up stk patches upstream. Only tested with latest upstream phonesim.  Let me know if I broke anything
Jul 30 22:41:08 <balrog-k1n> denkenz: i have a python agent that supports cancelling and stuff (you'll need that if the main menu will show up and then be invalidate by a new request repeatedly for very short moments)
Jul 30 22:43:57 <balrog-k1n> oh ok, main menu is not a request, but still :)
Jul 30 22:46:23 <denkenz> Feel free to improve what I made
Jul 30 22:46:29 <denkenz> I just wanted basic sanity checking
Jul 30 22:48:57 <denkenz> The most amount of time I spent on the silly immediate response crap
Jul 30 22:49:01 <denkenz> Such a stupid feature
Jul 30 22:50:02 <balrog-k1n> nod i also spent a while on it
Jul 30 22:50:27 <balrog-k1n> just mentioning the test agent cause it's good to not duplicate work
Jul 30 22:55:50 <balrog-k1n> i'm looking at http://git.kernel.org/?p=network/ofono/ofono.git;a=commitdiff;h=9684c4a36289a6075dceb5172f5344a69747e021 , the first check is for when no agent is registered and the second is for when a request like DisplayText is still active and the new one needs to invalidate it
Jul 30 22:58:51 <denkenz> We take care of both elsewhere
Jul 30 22:58:57 <denkenz> Don't see the point
Jul 30 23:01:32 <balrog-k1n> (not in that commit though)
Jul 30 23:03:44 <denkenz> Could be, but at that point I was ignoring the silly immediate response cases
Jul 30 23:05:19 <denkenz> However, I ended up forgetting the check in stk.c for the current_agent not being NULL, so that's a good catch
Jul 30 23:18:18 <denkenz> Ok, that part is now fixed
Jul 30 23:28:32 <balrog-k1n> in display_text_cb, in the comment, i guess 3. should say either case 1, 2, or 4 happens
Jul 30 23:29:58 <balrog-k1n> and in http://git.kernel.org/?p=network/ofono/ofono.git;a=commitdiff;h=e5ea6e2193062365eec7662d7866d306e8b56bcf since you're sending the response outside of the commands callback, i'm having difficulties convincing myself that you're never sending two responses accidentally
Jul 30 23:30:11 <balrog-k1n> (also the commit message seems unrelated to the content) :p
Jul 30 23:32:58 <denkenz> Ah whoops, good catch on that one
Jul 30 23:33:36 <denkenz> There are two ways through the system
Jul 30 23:33:52 <denkenz> One is for Agent jumped off the bus case which that patch is about
Jul 30 23:34:10 <denkenz> and then the regular handling
Jul 30 23:34:21 <denkenz> Invalid responses get treated as Agent jumping off the bus
Jul 30 23:35:13 <denkenz> 1,2,3 comment typo fixed
Jul 30 23:35:15 <balrog-k1n> ah, and callback is not called, just the request destroy callback? i think i see how it works
Jul 30 23:35:30 <denkenz> Yep
Jul 30 23:37:24 <balrog-k1n> in http://git.kernel.org/?p=network/ofono/ofono.git;a=commitdiff;h=c2cf3748575abdaf49193a6b5d7641fef593e9bf i think the check in stk_unregister will never trigger since the agent needs to be freed and that will take care of freeing the timeout source
Jul 30 23:37:36 <balrog-k1n> but doesn't hurt ofcourse
Jul 30 23:40:53 <denkenz> Yep you're right
Jul 30 23:52:13 <denkenz> Ok, that fix pushed as well
Jul 30 23:52:30 <denkenz> Probably some corner cases still lurking, needs more testing
**** ENDING LOGGING AT Sat Jul 31 02:59:57 2010