**** BEGIN LOGGING AT Mon Aug 23 02:59:57 2010
Aug 23 05:54:10 <yang_office> balrog-k2n: Some questions on stk: 1) Can we support more than one stk application at the same time? 2) Need we consider the terminal types (ND, NK, etc)? I think it may impact the behavior to call agent. 3) How to send the additional information in response? 
Aug 23 11:21:39 <balrog-k2n> yang_office: can you explain in more detail how concurrent stk applications work?
Aug 23 11:22:57 <balrog-k2n> yang_office: the standard says only one proactive command can be executing at a time, so if the multiple apps don't need to execute commands at the same time they should work
Aug 23 11:26:54 <balrog-k2n> yang_office: re 2) all the mentions of ND, NK, etc in the specs only say "for terminals of type ND/NK... this feature is optional" so as far as i can see there's nothing mandatory we have to do for such terminals
Aug 23 11:27:21 <balrog-k2n> we may only have to amend the TERMINAL PROFILE we're sending
Aug 23 11:28:44 <balrog-k2n> however i bet Denis prefers that we take some features for granted for simplicity (like presence of the display and keyboard/keypad/on-screen keypad)
Aug 23 11:31:36 <balrog-k2n> yang_office: re 3) do you mean the additional info field in the "Result" dataobj?
Aug 23 13:56:55 <pessi> when you plan to release the new ofono? any plans to sync with connman?
Aug 23 14:05:30 <holtmann> pessi: Soon.
Aug 23 14:05:57 <holtmann> I was going to let the connman-0.59 sit at least for one day. And then figure out on how do deal with the oFono API changes.
Aug 23 14:06:06 <holtmann> The current oFono code base is ready for a release.
Aug 23 14:09:51 <pessi> I'll try to throw in some fixes in sim handling
Aug 23 14:10:05 <holtmann> Sure.
Aug 23 14:10:10 <pessi> so we can get rid of online polling
Aug 23 14:11:48 <holtmann> That would be nice.
Aug 23 14:12:08 <holtmann> How do we handle the Online property support for all other modems btw. We need to get that fixed as well.
Aug 23 14:18:37 <pessi> sure... I can fix mbm and test it, but rest I'm very uncomfortable with
Aug 23 14:18:46 <holtmann> MBM would be a start.
Aug 23 14:20:27 <pessi> holtmann: I reubmitted my mbm robustness fixes, rebased against current head, have a peek on them
Aug 23 14:45:09 <pessi> hmhm... how the PIN2 stuff is intended to be handled? like, how you modify fdn?
Aug 23 14:50:15 <holtmann> We don't do FDN.
Aug 23 14:50:28 <holtmann> FDN is not useful in the context of a smartphone.
Aug 23 14:50:38 <pessi> sure, but what we do if modem wants to have pin2?
Aug 23 14:51:02 <holtmann> PinRequired will say PIN2.
Aug 23 14:51:24 <holtmann> Not that I ever tried this. Most providers don't even give you PIN2 and PUK2 these days.
Aug 23 14:53:12 <pessi> most providers don't know what for pin2 and puk2 are ;)
Aug 23 14:54:58 <holtmann> Exactly.
Aug 23 14:55:31 <holtmann> Do you have a test setup with a FDN enabled SIM card.
Aug 23 14:56:20 <holtmann> The only case oFono really cares is a SIM card where the provider or admin enabled FDN and we need to make these work.
Aug 23 14:56:27 <holtmann> Everything else is pointless.
Aug 23 16:42:32 <denkenz> Need to figure out what I wanna do this week
Aug 23 16:42:55 <denkenz> Anyone have anything pressing that needs attention?
Aug 23 16:49:10 <holtmann> denkenz: If Kristen is not looking into SIM ready notification, you might wanna have a stab at that. So we get that out of the way and can cleanup some mode plugins.
Aug 23 16:52:28 <denkenz> She has to tell me or to post a patch with the owner
Aug 23 16:52:46 <denkenz> Don't wanna interfere until then
Aug 23 16:52:59 <holtmann> kristenc: ping
Aug 23 16:54:43 <kristenc> holtmann: pong
Aug 23 16:55:02 <holtmann> See above. Are you working on SIM ready notification support?
Aug 23 16:55:15 <holtmann> If so, please send a patch to update the owner of the TODO item.
Aug 23 16:55:37 <kristenc> denkenz: holtmann: I was looking at it, but I've not really started on a patch yet, so if you would like to do that, I can go look at something else.
Aug 23 16:56:36 <kristenc> whatever you want.  I can also update the TODO list.  I was planning on working on the patch today and tomorrow, but can do something else instead.
Aug 23 16:56:51 <denkenz> Go ahead and take a stab at it
Aug 23 16:57:01 <kristenc> ok.
Aug 23 16:57:04 <holtmann> Yep. Work on it. Just send the TODO patch so we can track this properly.
Aug 23 16:57:47 <kristenc> ok - I'll send a patch in a couple hours, am not able to right this second.
Aug 23 16:58:55 <kristenc> unfortunately I've still got no way to test as majid had no modems for me and I've go to track inakypg down and take his.  so I'll test on phonesim I guess.
Aug 23 16:59:52 <pessi> mbm is only driver implementing the delay now 
Aug 23 17:00:17 <inakypg> kristenc: I have it here with me at AL
Aug 23 17:00:24 <inakypg> I'll leave it in today so you can come pick it up
Aug 23 17:00:38 <denkenz> phonesim should work just fine for the core changes
Aug 23 17:00:49 <kristenc> inakypg: I've no idea where you guys are.  Can you email me your pole and floor?
Aug 23 17:01:03 <holtmann> inakypg: Which modem do you have? At least MBM and Huawei send notifications for this.
Aug 23 17:01:08 <inakypg> AL-4 J8
Aug 23 17:01:13 <inakypg> Marcel: I think it is an mbm
Aug 23 17:01:50 <kristenc> inakypg: I'm in hillsboro getting my car fixed right now, so I will run by after they are done (which will be soon) and get it if that is ok.
Aug 23 17:02:08 <inakypg> sure it is
Aug 23 17:02:31 <kristenc> never been to AL - hope I can find it :).
Aug 23 17:03:07 <holtmann> inakypg: Half mini-PCI card? Then yes, it is an MBM since we have no other ones in that format.
Aug 23 17:03:40 <pessi> denkenz: ..and can you review my sim patch before kristenc gets in full speed?
Aug 23 17:03:42 <inakypg> yep, hmc, I have it in one of those grey craddles
Aug 23 17:04:04 <denkenz> pessi: Looking at it now
Aug 23 17:05:05 <denkenz> Ok, yuck :P
Aug 23 17:05:26 <denkenz> The CPHS changes are yucky and the delay is yucky
Aug 23 17:05:57 <holtmann> inakypg: Yep. That are the MBM ones.
Aug 23 17:07:56 <denkenz> pessi: What do you think of just moving the CPHS querying just before the IMSI query?
Aug 23 17:08:22 <denkenz> pessi: I also have another patch that reads EFust and EFest
Aug 23 17:13:17 <pessi> denkenz: like, 51.0011 me harder?
Aug 23 17:13:27 <pessi> go ahead
Aug 23 17:13:41 <denkenz> lol
Aug 23 17:14:11 <denkenz> Its 31.102 now ;)
Aug 23 17:20:06 <holtmann> ofonod[11331]: Pcui:> AT+CGATT=1\r
Aug 23 17:20:06 <holtmann> ofonod[11331]: Pcui:< \r\n^SRVST:1\r\n
Aug 23 17:20:06 <holtmann> ofonod[11331]: Pcui:< \r\n+CREG: 2\r\n\r\n+CGREG: 2\r\n\r\n^SRVST:2\r\n
Aug 23 17:20:06 <holtmann> ofonod[11331]: Pcui:< \r\n+CREG: 1, 5620, 474AB3\r\n\r\n+CGREG: 0\r\n
Aug 23 17:20:07 <holtmann> ofonod[11331]: Pcui:< \r\n^RSSI:3\r\n
Aug 23 17:20:07 <holtmann> ofonod[11331]: Pcui:< \r\n^RSSI:3\r\n
Aug 23 17:20:17 <holtmann> denkenz: I get this funny Huawei modem behavior.
Aug 23 17:20:24 <holtmann> CGATT never returns OK.
Aug 23 17:20:44 <denkenz> You know the drill
Aug 23 17:20:56 <denkenz> open_window(); throw_modem(huawei); close_window()
Aug 23 17:21:06 <Spider-Pork> lol
Aug 23 17:21:30 <Spider-Pork> CGATT never returns OK?
Aug 23 17:21:37 <holtmann> Yes it does.
Aug 23 17:21:39 <Spider-Pork> is strange
Aug 23 17:21:58 <pessi> it is huawei
Aug 23 17:22:02 <Spider-Pork> ah ok
Aug 23 17:22:06 <holtmann> denkenz: I must be some funny race condition.
Aug 23 17:22:32 <Spider-Pork> CGATT is an AT command
Aug 23 17:22:50 <pessi> of course, only the modems you have not tried are not strange
Aug 23 17:22:51 <Spider-Pork> the module MUST respond with OK (I think)
Aug 23 17:23:06 <Spider-Pork> to be compatible with AT commands
Aug 23 17:23:33 <Spider-Pork> OK or ERROR
Aug 23 17:23:46 <pessi> mbm echoes some internal AT commands while it initializes itself 
Aug 23 17:24:57 <Spider-Pork> Do you use a delay between last command and AT+CGATT?
Aug 23 17:25:24 <Spider-Pork> some modules needs it
Aug 23 17:27:35 <holtmann> ofonod[11614]: Pcui:> AT+CGATT=1\r
Aug 23 17:27:36 <holtmann> ofonod[11614]: Pcui:< \r\n^MODE:3,3\r\n
Aug 23 17:27:36 <holtmann> ofonod[11614]: Pcui:< \r\n^MODE:3,3\r\n
Aug 23 17:27:36 <holtmann> ofonod[11614]: Pcui:< \r\n+CREG: 1, 560E, 6E32\r\n\r\n+CGREG: 1, 560E, 6E32\r\n
Aug 23 17:27:37 <holtmann> ofonod[11614]: Pcui:< \r\nOK\r\n
Aug 23 17:27:45 <holtmann> This is when it works just fine.
Aug 23 17:28:11 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:huawei_gprs_activate_primary() 
Aug 23 17:28:11 <holtmann> ofonod[11614]: Modem:> AT+CGDCONT=1,"IP","ca.t-mobile"\r
Aug 23 17:28:11 <holtmann> ofonod[11614]: Modem:< \r\nOK\r\n
Aug 23 17:28:11 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:at_cgdcont_cb() 
Aug 23 17:28:13 <holtmann> ofonod[11614]: Modem:> AT^NDISDUP=1,1\r
Aug 23 17:28:13 <holtmann> ofonod[11614]: Modem:< \r\nOK\r\n
Aug 23 17:28:15 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:at_ndisdup_up_cb() 
Aug 23 17:28:16 <holtmann> ofonod[11614]: Modem:> AT^DHCP?\r
Aug 23 17:28:17 <holtmann> ofonod[11614]: Modem:< \r\n+CME ERROR: 1\r\n
Aug 23 17:28:19 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:dhcp_query_cb() 
Aug 23 17:28:22 <holtmann> ofonod[11614]: Modem:> AT^DHCP?\r
Aug 23 17:28:23 <holtmann> ofonod[11614]: Modem:< \r\n^DHCP:f73cbb50,f0ffffff,f13cbb50,f13cbb50,16534a0a,1a0fec1,236800,236800\r\n\r\nOK\r\n
Aug 23 17:28:26 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:dhcp_query_cb() 
Aug 23 17:28:28 <holtmann> ofonod[11614]: drivers/huaweimodem/gprs-context.c:dhcp_query_cb() 
Aug 23 17:28:33 <holtmann> And in case anybody ever figures out how to drive the NDIS port of the Huawei modem.
Aug 23 17:34:03 <denkenz> shakes his head and goes back to 11.11, 51.011 and 31.102 mess
Aug 23 17:35:50 <Spider-Pork> generally i have these kind of problems while giving multicommands with too small delay
Aug 23 17:36:36 <holtmann> denkenz, pessi: So what do we wanna have merged before the next release?
Aug 23 17:37:16 <denkenz> Spider-Pork: oFono uses a queue and only submits the next command when the previous one has been given a final result
Aug 23 17:38:04 <denkenz> Spider-Pork: I have yet to see a modem that needed a delay between final result and the next command
Aug 23 17:46:08 <Spider-Pork> siemens MC55 needs 1/10 seconds between commands
Aug 23 17:49:50 <denkenz> jeez, that's slow
Aug 23 17:50:07 <denkenz> Sounds like someone needs to write a delay feature into g_at_chat
Aug 23 17:51:05 <pessi> holtmann: 51.011 stuff from denkenz? ofono_sim_ready_notify tms from kristenc?
Aug 23 17:51:54 <denkenz> erm, who's in charge here? Oh I forget I'm the maintainer
Aug 23 17:52:24 <denkenz> holtmann: You need to check with sameo and pessi as to when the Online handling is ready
Aug 23 17:52:45 <denkenz> If it can be ready soon, then lets shoot for another release with sim_ready notifications and online driver conversion
Aug 23 17:52:55 <denkenz> Lets say end of this week
Aug 23 17:54:19 <Spider-Pork> denkenz, wait, 1/10 of second
Aug 23 17:54:26 <Spider-Pork> not from1 to 10 seconds
Aug 23 17:54:28 <Spider-Pork> sorry
Aug 23 17:54:38 <denkenz> That is still an eternity
Aug 23 17:54:48 <denkenz> You should see how fast oFono can initialize an MBM card
Aug 23 17:54:51 <Spider-Pork> I am on holidays and i not have here the datasheet
Aug 23 17:55:04 <denkenz> I'm talking about ~100 commands in a few seconds
Aug 23 17:55:05 <Spider-Pork> next week i will give you the ds
Aug 23 17:55:06 <Spider-Pork> wow
Aug 23 17:55:11 <Spider-Pork> mc55 is not so fast
Aug 23 17:55:29 <Spider-Pork> remember me that if i will forgot to give you the ds
Aug 23 17:55:39 <denkenz> Sure
Aug 23 17:56:23 <Spider-Pork> in general, i have noticed that module needs more delay when the command access some data stored inside
Aug 23 17:56:38 <Spider-Pork> like adress book
Aug 23 17:56:47 <denkenz> Still, it gives back a final response code
Aug 23 17:56:52 <denkenz> There should be no need for a delay
Aug 23 17:56:56 <Spider-Pork> or cpin
Aug 23 17:57:04 <Spider-Pork> i know
Aug 23 17:57:31 <Spider-Pork> but the ds says that the module needs 1/10 of second
Aug 23 17:57:53 <Spider-Pork> same for mc55i
Aug 23 17:58:03 <Spider-Pork> the new version of mc55
Aug 23 17:58:52 <Spider-Pork> iI'll check for hc25
Aug 23 17:59:11 <Spider-Pork> as for mc55 I have the ds at office
Aug 23 17:59:39 <holtmann> denkenz: Sounds good. Lets wait a little bit while we are looking into needed ConnMan changes.
Aug 23 17:59:59 <holtmann> denkenz: However end of the week I gonna make a release no matter what. I am off next week.
Aug 23 18:00:22 <denkenz> Well its sameo's / your call
Aug 23 18:00:39 <denkenz> The ofono changes are actually trivial, at least for mbm/hso/huawei
Aug 23 18:01:21 <holtmann> I am all for this. So lets get this done.
Aug 23 18:01:26 <holtmann> MBM patch looks fine to me.
Aug 23 18:03:15 <pessi> online?
Aug 23 18:04:15 <holtmann> Yes. We have to do ConnMan changes anyway for the API that changed inside oFono, why not get the Online support done at the same time.
Aug 23 18:08:10 <holtmann> denkenz: The PinRequired = none signal submission needs to be also done.
Aug 23 18:10:21 <denkenz> Yeah I do that
Aug 23 18:15:46 <holtmann> We don't wanna do something like PinRequired = offline in case Offline = true. So that the property is always present?
Aug 23 18:16:31 <pessi> if sim is present?
Aug 23 18:19:15 <denkenz> PinRequired shouldn't be queried unless Inserted=True
Aug 23 18:26:34 <holtmann> I know. Just for the sake of having the property around all the time.
Aug 23 18:30:14 <pessi> denkenz: btw, can you unlock pin2 with AT commands?
Aug 23 18:30:28 <denkenz> pessi: Generally no
Aug 23 18:32:14 <denkenz> holtmann: Then you mean PinRequired="removed" or something
Aug 23 18:32:41 <denkenz> Personally it looks a bit ugly to me
Aug 23 19:33:57 <denkenz> pessi: Ok I pushed the changes, see if your IMSI problem has gone away now
Aug 23 19:39:02 <holtmann> denkenz: Stupid Huawei. This is a DNS server 1a0fec1. So it is hex, but the leading 0 is missing to make it an even number hexstring :(
Aug 23 19:39:28 <denkenz> haha
Aug 23 19:39:35 <denkenz> That's hilarious ;)
Aug 23 19:40:12 <denkenz> Suppose you can do a simple strtol
Aug 23 19:40:42 <denkenz> GAtResult can get you close enough to be able to do that easily
Aug 23 19:41:43 <holtmann> Problem is that GAtChat doesn't skip to next result.
Aug 23 19:41:47 <holtmann> It that intentional?
Aug 23 19:42:00 <holtmann> 	if ((end - pos) & 1)
Aug 23 19:42:00 <holtmann> 		return FALSE;
Aug 23 19:42:05 <holtmann> It should be goto out.
Aug 23 19:42:19 <holtmann> I am using g_at_result_iter_next_hexstring.
Aug 23 19:42:20 <denkenz> Sorry, paste the line
Aug 23 19:42:36 <denkenz> AFAIK hexstring does the proper thing
Aug 23 19:42:45 <denkenz> Since the hex string itself must be even
Aug 23 19:42:57 <holtmann> Nope. It doesn't skip to next item if the string is uneven.
Aug 23 19:43:18 <denkenz> Yeah, but it shouldn't
Aug 23 19:43:18 <holtmann> It just does return FALSE instead of goto out.
Aug 23 19:43:30 <holtmann> So this is on propose that it doesn't skip.
Aug 23 19:43:36 <denkenz> g_at_result_* does not consume if something fails
Aug 23 19:43:41 <denkenz> we rely on that throughout the code
Aug 23 19:43:45 <holtmann> Fair enough. I was just checking.
Aug 23 19:49:03 <denkenz> However, GAtResult can get you the raw line
Aug 23 19:49:12 <denkenz> So strtol is simple enough for that case
Aug 23 19:49:57 <denkenz> Someone should ask Huawei why IP notation was not good enough
Aug 23 19:50:17 <denkenz> Do they expect ntohl/htonl to be called as well?
Aug 23 19:57:11 <holtmann> No idea.
Aug 23 19:57:15 <holtmann> I assume not.
Aug 23 19:57:40 <holtmann> Anyhow, I have that atom driver ready now.
Aug 23 19:57:42 <holtmann> Works fine for me.
Aug 23 20:01:04 <holtmann> denkenz: And if I do hexdump /dev/ttyUSB1 and try to ssh into that GPRS connection, I see packets.
Aug 23 20:01:47 <denkenz> nice
Aug 23 20:02:34 <holtmann> Btw. I have to poll ^DHCP since there is not notification when context setup has been done :(
Aug 23 20:03:24 <holtmann>         Settings = { DomainNameServers=10.74.83.22,193.254.160.1, Method=static Netmask=255.255.255.252 Address=88.128.26.85 Interface=invalid Gateway=88.128.26.86 }
Aug 23 20:03:36 <holtmann> And Interface name is invalid since we have no kernel driver for the network interface yet.
Aug 23 20:03:49 <denkenz> heh
Aug 23 20:04:06 <holtmann> Other than that, this actually works.
Aug 23 20:10:26 <holtmann> denkenz: Pushed it.
Aug 23 20:10:43 <holtmann> Not very pretty, but if someone wants to have a play with the NDIS stuff, then can now.
Aug 23 20:12:22 <denkenz> I thought Huawei told us that the NDIS driver was already upstream
Aug 23 20:12:28 <denkenz> just needs the usb ids tweaked
Aug 23 20:14:47 <holtmann> Could be.
Aug 23 20:37:34 <holtmann> denkenz: Btw. I am fine with two Online patches. Lets take them in and see how it goes.
Aug 23 20:37:55 <holtmann> Huawei is bit nasty actually.
Aug 23 20:38:06 <holtmann> It is picky from which mode you can switch into the other one.
Aug 23 20:41:27 <denkenz> I wanna hold on until ConnMan is ready
Aug 23 20:49:39 <holtmann> ConnMan is broken right now anyway, because of the API change.
Aug 23 20:49:44 <holtmann> So no harm done.
Aug 23 20:49:46 <holtmann> ofonod[21071]: 2nd:> AT+CRSM=192,12037\r
Aug 23 20:49:46 <holtmann> ofonod[21071]: 2nd:< \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
Aug 23 20:49:51 <holtmann> Is this a bad sign btw?
Aug 23 20:51:09 <holtmann> Better than this.
Aug 23 20:51:10 <holtmann> ofonod[21135]: 2nd:> AT+CRSM=192,12037\r
Aug 23 20:51:10 <holtmann> ofonod[21135]: 2nd:< \r\n+CME ERROR: 21\r\n
Aug 23 20:52:26 <denkenz> 144,0,"" means it needs the QUALCOMM_MSM quirk
Aug 23 20:54:04 <holtmann> AT$QCSIMSTAT=?
Aug 23 20:54:04 <holtmann> $QCSIMSTAT: (0-1)
Aug 23 20:54:04 <holtmann> OK
Aug 23 20:54:04 <holtmann> AT$QCSIMSTAT?
Aug 23 20:54:05 <holtmann> $QCSIMSTAT: 0,SIM INIT COMPLETED
Aug 23 20:54:05 <holtmann> OK
Aug 23 20:54:07 <holtmann> AT$QCSIMSTAT=1
Aug 23 20:54:09 <holtmann> OK
Aug 23 20:54:11 <holtmann> AT$QCSIMSTAT?
Aug 23 20:54:13 <holtmann> $QCSIMSTAT: 1,SIM INIT COMPLETED
Aug 23 20:54:15 <holtmann> OK
Aug 23 20:54:20 <holtmann> Qualcomm added a SIMSTAT command to the newer firmware found in the Novatel cards.
Aug 23 20:58:53 <denkenz> holtmann: Yeah but the API change so far has been trivial, this gets tricky
Aug 23 20:59:56 <denkenz> The patches are fine though I agree, so we can apply anytime
Aug 23 21:00:16 <holtmann> ofonod[21504]: 1st:> AT+CFUN=1\r
Aug 23 21:00:16 <holtmann> ofonod[21504]: 1st:< \r\nERROR\r\n
Aug 23 21:00:16 <holtmann> ofonod[21504]: 2nd:< \r\nOK\r\n
Aug 23 21:00:16 <holtmann> ofonod[21504]: 2nd:> AT$CNTI=2\r
Aug 23 21:00:16 <holtmann> ofonod[21504]: 2nd:< \r\n$CNTI: 2, GPRS, EDGE, UMTS, HSDPA, HSUPA\r\n\r\nOK\r\n
Aug 23 21:00:16 <holtmann> ofonod[21504]: 2nd:> AT$QCSIMSTAT=1\r
Aug 23 21:00:19 <holtmann> ofonod[21504]: 2nd:< \r\nOK\r\n
Aug 23 21:00:20 <holtmann> ofonod[21504]: 1st:< \r\n$QCSIMSTAT: 1 SIM INIT COMPLETED\r\n
Aug 23 21:00:22 <holtmann> ofonod[21504]: 1st:< \r\n$QCSIMSTAT: 1 SIM INIT COMPLETED\r\n
Aug 23 21:00:24 <holtmann> ofonod[21504]: 2nd:< \r\n$QCSIMSTAT: 1 SIM INIT COMPLETED\r\n
Aug 23 21:00:29 <holtmann> Novatel card. With failing CFUN=1.
Aug 23 21:02:24 <denkenz> Sweet
Aug 23 21:02:38 <denkenz> But then again, that's what sim_ready is all about ;)
Aug 23 21:06:40 <holtmann> And only supported by the MC990D and not the MC950D :(
Aug 23 21:08:37 <holtmann> I have to redo that modem plugin eventually.
Aug 23 21:18:17 <holtmann> denkenz: Let me sleep about this, but I am considering applying the Online patches and then fixing up ConnMan.
Aug 23 21:18:35 <holtmann> pessi: Unless you beat me to it since I still have some other pieces to sort out first.
Aug 23 21:19:03 <holtmann> denkenz: However the PinRequired D-Bus signal seems to needed to make this work nicely.
Aug 23 21:19:29 <holtmann> A few pieces we have to get working before this looks good again :(
Aug 23 21:21:54 <denkenz> of course
Aug 23 21:23:40 <pessi> holtmann: einprogress 
Aug 23 22:08:22 <kristenc> denkenz: ping
Aug 23 22:08:33 <denkenz> kristenc: pong
Aug 23 22:10:40 <kristenc> denkenz: I have a question about retrieving the imsi.  Looking at the code in src/sim.c, it looks like we only call retrieve_imsi() if the pin_type is PASSWORD_NONE or if the driver does not present a method of querying the passwd.  So does that mean if the sim requires a password, we never read IMSI?  That doesn't seem right.
Aug 23 22:11:19 <denkenz> We start in password_none state
Aug 23 22:12:38 <denkenz> So the assumption is that is query_pin/enter_pin are not provided, then we don't deal with PINs
Aug 23 22:14:35 <mikeleib> CallBarring::ChangePassword() doesn't give me any return data
Aug 23 22:14:43 <mikeleib> shall I assume that there is no "wrong" answer for this?
Aug 23 22:15:02 <mikeleib> for example, what happens when old_password is wrong?
Aug 23 22:15:07 <kristenc> that part makes sense.  but I don't understand how we get to read imsi if there is a query_pin provided.
Aug 23 22:16:01 <kristenc> or - maybe you don't need to read IMSI if you have a pin?
Aug 23 22:16:43 <denkenz> kristenc: You have to follow the bread crumbs
Aug 23 22:16:56 <denkenz> We read the IMSI after reading EFest
Aug 23 22:17:29 <denkenz> look at sim_initialize_after_pin and search for sim_retrieve_imsi
Aug 23 22:17:55 <denkenz> Compliance with the spec is the reason for all this silliness, it mandates a certain order
Aug 23 22:18:09 <kristenc> hum, I must need to re-pull.  I don't see that.
Aug 23 22:18:27 <mikeleib> denkenz: holtmann ??
Aug 23 22:18:30 <kristenc> come to think of it, it's been a few days since I pulled the repo.
Aug 23 22:18:32 <denkenz> mikeleib: ChangePassword returns void
Aug 23 22:19:01 <denkenz> mikeleib: If it fails, it will return an org.ofono.Error.*
Aug 23 22:19:11 <mikeleib> abuse of returns void
Aug 23 22:19:44 <denkenz> Not really
Aug 23 22:19:54 <denkenz> Welcome to the world of exceptions
Aug 23 22:20:01 <denkenz> DBus errors map nicely to that
Aug 23 22:20:25 * mikeleib disagrees
Aug 23 22:20:47 <denkenz> Please write a letter to org.freedesktop.DBus
Aug 23 22:21:51 <mikeleib> the more I use DBus, the more I dislike it.  They go around telling everyone it's a message passing interface and everyone goes around treating it like an ORB.  It sucks as an ORB
Aug 23 22:22:30 <mikeleib> anyway.. does this have it's own org.ofono.Error?? or is there a generic one it uses with a special message?
Aug 23 22:22:44 <mikeleib> also.. note in docs would be nice
Aug 23 22:23:07 <denkenz> Most likely it will return org.ofono.Failed
Aug 23 22:23:15 <denkenz> err .Error.Failed
Aug 23 22:23:32 * mikeleib noodles on how to best present this to the user
Aug 23 22:23:55 <denkenz> "Password change failed'?
Aug 23 22:24:17 <mikeleib> "N00B!"
Aug 23 22:26:42 <denkenz> Ok..
Aug 23 22:28:28 <mikeleib> what I really meant, was how I can pop this into the UX well.  The string itself is easy to change
Aug 23 22:28:48 * mikeleib will noodle on it..
Aug 23 22:28:50 <mikeleib> thanks denkenz 
Aug 23 22:29:42 <kristenc> denkenz: ok, so now I have the sim_initialize_after_pin() function, but I have the same question.  It gets called if (pin_type == OFONO_SIM_PASSWORD_NONE), and if there is no query_pin.  But what if pin_type is something other than NONE?  How do we then go through with the rest of initialization?
Aug 23 22:30:22 <denkenz> kristenc: If the modem is expecting us to enter a PIN, and the modem driver is not providing query_pin function
Aug 23 22:30:34 <denkenz> Then that's major fail by the driver integrator
Aug 23 22:30:51 <denkenz> All subsequent requests will fail and we never get to online state
Aug 23 22:31:42 <balrog-k2n> kristenc: it always has to become NONE at some point
Aug 23 22:31:55 <balrog-k2n> usually as a result of EnterPin()
Aug 23 22:32:04 <kristenc> ok - I am clearly not communicating my question right :).  Thank you balrog-k2n that is what I was wondering.
Aug 23 22:32:37 <denkenz> 'if there is no query_pin' 
Aug 23 22:32:43 <denkenz> That translates to query_pin == NULL
Aug 23 22:32:47 <denkenz> But maybe I'm weird
Aug 23 22:33:11 <kristenc> denkenz: you are reading it wrong - I need to use more commas or something.  nevermind.
Aug 23 22:35:48 <denkenz> Sorry, my brain is interpreting that differently, but yeah, what balrog-k2n said
Aug 23 22:36:20 <kristenc> yes - I see now that sim_pin_check is called again after enter_pin, so that makes perfect sense now.
Aug 23 22:39:59 <thiago_syst> hey guys. I have a question regarding huawei support
Aug 23 22:40:13 <thiago_syst> is the drivers/haweimodem/ code supposed to replace the plugins/huawei.c one?
Aug 23 22:41:44 <denkenz> nope, its simply there for the new high-speed gprs_context driver
Aug 23 22:41:59 <denkenz> Some huaweis can do high-speed using NDIS interface instead of ppp
Aug 23 22:42:22 <denkenz> In the future oFono can detect what type of Huawei card it is, and instantiate either a ppp or a high speed context
Aug 23 22:43:51 <denkenz> To translate it simply, ofono_gprs_context_create(..."huaweimodem", ...) instead of ofono_gprs_context_create(....,"atmodem", ...)
Aug 23 22:44:53 <thiago_syst> I think I got it :) tks
Aug 24 00:06:36 <mikeleib> denkenz: in carrbarring, I see introspection for SetProperty giving me a signature of s,v,s
Aug 24 00:07:11 <mikeleib> denkenz: that's not what call-barring-api.txt says.  Is this a BUG?
Aug 24 00:08:18 <denkenz> Carr Barring is some sort of vehicle traffic management system?
Aug 24 00:08:34 <denkenz> I'm here all week ;)
Aug 24 00:08:36 <mikeleib> yes
Aug 24 00:08:38 <denkenz> Anyway, yes it is a bug
Aug 24 00:08:40 <mikeleib> w00t
Aug 24 00:08:46 <mikeleib> it makes my crap not compile
Aug 24 00:08:59 <mikeleib> known or unknown?  should I file?
Aug 24 00:09:15 <denkenz> Don't bother, I fix it
Aug 24 00:09:19 <denkenz> Its just a doc bug
Aug 24 00:09:32 <denkenz> The introspection is actually correct
Aug 24 00:09:34 <mikeleib> so, it is s,v,s ?
Aug 24 00:10:51 <denkenz> yep
Aug 24 00:14:22 <denkenz> fix to docs pushed
Aug 24 00:15:53 <mikeleib> commit id?
Aug 24 00:16:26 * mikeleib sees last commit as 565ea1f8a....
Aug 24 00:16:59 <denkenz> takes a sec for kernel.org to sync
Aug 24 00:17:03 <denkenz> check back in 5 min or so
Aug 24 00:17:15 <denkenz> However, it is purely a doc fix, doesn't affect the functionality
Aug 24 00:17:25 * mikeleib is dying to know what the last s is for.  This is a strange new way for marcel type APIs to werk
Aug 24 00:18:10 * mikeleib gets commit
Aug 24 00:18:21 <mikeleib> pin2.. gah!
Aug 24 00:18:36 <mikeleib> this breaks my SET_MARCEL_PROPERTY macro
Aug 24 00:19:24 <zhenhua1> holtmann: which huawei modem are u testing for NDIS? I don't find NDIS port on my EM770W although it said it should have...
Aug 24 00:20:21 <zhenhua1> holtmann: if you wanna asking some questions to huawei guy, i have their TME's email info, although i am not sure whether they are glad to help us.
Aug 24 00:26:54 <mikeleib> denkenz: is pin2 the same as the password in changepassword?
Aug 24 00:39:53 <denkenz> yes
**** ENDING LOGGING AT Tue Aug 24 02:59:57 2010