**** BEGIN LOGGING AT Thu Aug 26 02:59:57 2010 Aug 26 03:07:47 balrog-k1n: What's the purpose of dial_cancel? Aug 26 03:11:05 denkenz: so we can ensure we don't get called back (could be fatal e.g. if the atom was destroyed in the meantime) Aug 26 03:11:20 also we may want to release the call if it's still alerting Aug 26 03:11:58 denkenz: will do - will send you something tomorrow hopefully. Aug 26 03:17:35 balrog-k1n: Ok Aug 26 03:17:38 couple other things: Aug 26 03:17:41 dial_request_cb Aug 26 03:17:44 On the goto done part Aug 26 03:18:41 If the call fails, is there a chance we simply return in the done label? Aug 26 03:19:37 also, why do we need __voicecall_busy if we return EBUSY error? Aug 26 03:20:04 if the call fails we need to invoke the callback and free the struct Aug 26 03:21:07 we could do without it, but i thought it didn't make sense even asking the user if they want to set the call up if they're talking on the phone Aug 26 03:21:16 so we can immediately return busy Aug 26 03:22:36 (this is done in the 3rd patch) Aug 26 03:23:18 Hm, you actually call it twice Aug 26 03:23:23 The second time in confirm_cb Aug 26 03:24:27 ah you're right the second usage doesn't give us anything Aug 26 03:26:07 The only thing I don't like is how you duplicate the entirety of dial_callback Aug 26 03:26:21 And that one's not trivial Aug 26 03:27:22 right, dial_callback is tied to d-bus Aug 26 03:27:27 maybe we can have a common handler Aug 26 03:28:17 it gets tricky because we try to reply to method calls and emit signals in the right order Aug 26 03:28:32 But yeah, that needs to be put into a common function if at all possible Aug 26 03:29:19 Another thing Aug 26 03:29:34 102.223 talks about how Setup Call should not be tracked in call history Aug 26 03:29:41 So that's another thing missing Aug 26 03:31:56 Otherwise it looks good to me Aug 26 03:38:32 to cache icon or image, i would suggest using some hash algorithm like md5 or sha256 Aug 26 03:38:49 they are fast and safe Aug 26 03:46:05 md5 or sha256 is not helpful here Aug 26 03:46:22 We're trying to cache the images on the filesystem to avoid long roundtrips to the modem / sim Aug 26 04:45:26 denkenz: is call barring something that is a carrier optional supplementary service? Aug 26 04:57:36 yes Aug 26 04:57:51 nobody in the us uses it Aug 26 05:42:30 crap. How do I test this? Aug 26 05:43:09 do they use it down under? Aug 26 05:43:54 I think so Aug 26 05:44:41 But honestly didn't try down there **** BEGIN LOGGING AT Thu Aug 26 09:33:24 2010 Aug 26 11:31:55 denkenz: how to add fdn disable/enable, new method in sim_driver or new password type for fdn? Aug 26 11:45:48 which MBM modem is the newest? Is it F3507g? Aug 26 11:46:32 So that would be then the Dell D5530 card Aug 26 11:47:50 someone mentioned 3705, but I'm not sure if that exists Aug 26 11:47:56 d5530 is crap Aug 26 11:48:14 I'd like to get one of the MBM Aug 26 11:48:55 new verison of course, so that there is the EPSB Aug 26 11:49:13 which is somewhre near the CPSB Aug 26 11:49:40 I heard that all modems are crap :) Aug 26 11:50:04 my card does not work with Elisa SIMs (SIM ATK gets it crashed) Aug 26 11:50:37 sounds like crap Aug 26 11:50:56 but you can confirm that f3507g is rather new? Aug 26 11:51:07 all modems are crap, but some SIM cards are crap, too Aug 26 11:51:55 I have no idea, the manufacture week is 2010/15 Aug 26 11:53:02 hmm, the f3507g press release is from 2008 Aug 26 11:57:03 {SimManager} [/3558620259880190] PinRequired = puk2 Aug 26 11:57:20 now this is something new ;) Aug 26 11:58:28 I didn't follow to closely the discussions about the PIN. Is it now resolved? Aug 26 11:58:54 huh? Aug 26 11:59:12 I don't think so Aug 26 12:00:00 ah okay. Wasn't the question how could be a SIM be identified automatically in order to enter the PIN without user interaction Aug 26 12:01:16 wagi: how is that a good idea? Aug 26 12:02:39 akiniemi: if you authenticate yourself through login into an account (e.g. your KDE session) you could associate the desktop session to the PIN so that you don't to remember/enter the pin all the time you go online Aug 26 12:05:36 wagi: perhaps the CardIdentifier property is available before PIN? Aug 26 12:06:20 with slightly less crappy modems Aug 26 12:23:14 akiniemi: at least on HSO modem it is not. Aug 26 12:23:36 akiniemi: anyway, I think the workaround for this is to disable the PIN Aug 26 13:32:43 pessi: The f36xx are the newer ones. And then they have even newer models, but I have never seen them so far. Aug 26 14:12:13 holtmann: tnx Aug 26 14:12:36 wagi: and this crap seems to have at*epsb Aug 26 14:12:37 * wagi has already ordered an f3507g Aug 26 14:12:56 cool Aug 26 14:13:19 pessi: thanks for the heads up Aug 26 14:14:03 yes, the f36xx supports EPSB. Aug 26 15:15:34 kristen: ping? Aug 26 15:35:00 Isn't the Dell 5540 a better idea? That's a F3607 Aug 26 16:04:51 denkenz: ah, I guess that's the one I should order. Luckely, my boss hasn't approved it the order. so let me change it :) Aug 26 16:05:53 denkenz: do you have your PUK2 code handy? Aug 26 16:06:33 I could get an old huawei from drawer and see what it says to my PIN2s Aug 26 16:07:25 Erm, no SIMs I have ship with a PUK2 Aug 26 16:08:15 This is all stupid anyway Aug 26 16:08:30 So complicated nobody can get it right Aug 26 16:18:30 denkenz: so this sim ready stuff Aug 26 16:18:52 yep Aug 26 16:18:57 when ofono driver starts, we can have modem up and running and SIM ready Aug 26 16:18:59 no events Aug 26 16:19:35 yep, that's what mbm does Aug 26 16:19:56 so if no PIN is required we try to read IMSI Aug 26 16:20:13 if that fails, we check if a ready event has received meanwhile Aug 26 16:20:23 and redo post-pin init Aug 26 16:20:51 Yeah, see that is not good, because we read a ton of sim files in the meantime Aug 26 16:21:13 so if some of them fail, but imsi succeeds, then we're still screwed Aug 26 16:21:26 should we retry in any case if ready event has been recceived? Aug 26 16:21:45 I think we need to always wait actually Aug 26 16:21:55 and have the driver tell us it is safe to proceed Aug 26 16:22:18 and the part where you got lost, that is sim_set_state(sim, OFONO_SIM_STATE_INSERTED) for the case where user has PUKed his SIM on the fly Aug 26 16:22:51 So I'm still confused about that Aug 26 16:22:59 CPIN? -> PIN Aug 26 16:23:05 we enter incorrect 3 times Aug 26 16:23:08 CPIN? -> PUK Aug 26 16:23:20 The current code already handles this AFAIK Aug 26 16:23:43 after READY, you try to change your PIN. enable it. disable it. Aug 26 16:24:04 after three times, you got PUKed Aug 26 16:24:14 Ok that case Aug 26 16:25:05 so you feel that after PIN check core should wat for ready_notify in any case? Aug 26 16:25:42 That is my current feeling Aug 26 16:25:50 Basically calypso, hso, huawei work this way Aug 26 16:26:02 Probably all other qualcomm based ones Aug 26 16:26:31 Only mbm doesn't tell us anything Aug 26 16:26:54 and quirk 0 would be to call ready_notify if pin_check result is none? Aug 26 16:27:00 hm? Aug 26 16:27:11 I suspect so Aug 26 16:27:21 I started playing with it yesterday, but not very long Aug 26 16:27:26 Those are my impressions so far Aug 26 16:27:42 mbm only tells us about EPEV, nothing if sim is not pin locked Aug 26 16:29:18 So for the PUK'ed after inserted case, we need to run PIN queries after each Lock / Unlock Aug 26 16:29:45 sure Aug 26 16:30:02 Can we treat this as a sim removal / insertion? Aug 26 16:30:11 Its kind of hard to notify the UI of such a case Aug 26 16:30:20 you really want to read ton of files? Aug 26 16:30:46 iow, eficcd Aug 26 16:31:06 removal/insertion after PUKed is fine Aug 26 16:31:14 I don't know really, this is a hard case Aug 26 16:31:21 The thing is that we need to tell the UI something Aug 26 16:31:45 And the atoms most likely need to get removed Aug 26 16:32:13 Then again, half the shit will work because the modem caches the SIM in its memory ;) Aug 26 16:35:00 at some point, they want to use RES and get hosed Aug 26 16:35:19 like sim hotswap, but not quite Aug 26 16:35:46 thinking again, quirk 0 would be to Aug 26 16:36:05 1) call ready_notity after each enter pin, let core to check pin state Aug 26 16:37:01 2) call check pin after each enter pin from driver, let core know the pin state .. like a parameter to ready_notify()? Aug 26 16:39:12 1) successful enter_pin, no? Aug 26 16:40:16 dunnoh. if it is unsuccessful, the check_pin should catch it? Aug 26 16:40:57 if its unsuccessful, calling sim_ready_notify is just a waste of CPU Aug 26 16:41:24 However, the problem is that the driver lacks context of what PIN is being entered Aug 26 16:42:00 or the at parser barfed because overeager stk sent tons of stuff immeidiately after PIN was enterd? Aug 26 16:42:23 at parser doesn't barf ;) Aug 26 16:42:28 If it does, you have bigger problems Aug 26 16:42:49 sure, like on mbm, modem crashes Aug 26 16:43:24 Yeah, but then decent hardware actually informs us Aug 26 16:44:53 I'd say we do it something like: Aug 26 16:45:07 at_pin_send_cb: Aug 26 16:45:27 if failure, callback and return Aug 26 16:45:42 if vendor == MBM, register EPEV Aug 26 16:45:48 it would be more robust to do check pin state after each pin code entered on random quirk 0 firmware Aug 26 16:45:55 if vendor == 0, callback, then call ready Aug 26 16:46:18 and it would make sense to register epev when sim driver is initialized Aug 26 16:46:31 just in case. Aug 26 16:46:57 EPEV can be registered any time Aug 26 16:46:57 or do they consume lot of CPU? ;-) Aug 26 16:47:31 well, the core checks PIN after each code has been entered Aug 26 16:47:37 Or do you mean something else here? Aug 26 16:47:50 yes, and *that* is waste of CPU Aug 26 16:48:06 Why? Aug 26 16:48:40 We cannot detect PIN -> PUK, or PIN -> CORPPIN transitions otherwise Aug 26 16:48:50 you have to check it after ready_notify in any case Aug 26 16:49:28 and if ready_notify comes after each check_pin Aug 26 16:49:40 we magically detect pin transitions Aug 26 16:50:10 We can do one or the other, I'm saying don't do both Aug 26 16:50:28 Here's the flow I'm trying to solve Aug 26 16:50:31 CPIN -> PIN Aug 26 16:50:35 enter_pin -> failed Aug 26 16:50:37 query Aug 26 16:50:40 CPIN -> PIN Aug 26 16:50:44 enter_pin -> success Aug 26 16:50:46 .. Aug 26 16:50:47 ... Aug 26 16:50:47 .. Aug 26 16:50:50 ready Aug 26 16:50:56 CPIN? -> CORP PIN Aug 26 16:51:05 enter_pin -> success Aug 26 16:51:08 CPIN -> READY Aug 26 16:51:55 oh, add a timer to call notify after enter_pin failed? Aug 26 16:52:18 ... a long timer Aug 26 16:52:35 not following Aug 26 16:52:45 so like, enter_pin_cb: Aug 26 16:52:48 if enter_pin failed, we can query right away Aug 26 16:52:56 sure Aug 26 16:53:32 enter_pin_cb: Aug 26 16:53:43 if not ok, ready_notify, return Aug 26 16:53:52 if ok, quirk mbm, return Aug 26 16:54:01 ready_notify Aug 26 16:54:24 and in ready_notify, check pin, update PinRequred and proceed Aug 26 16:54:48 So you want to check pin only in ready_notify... Aug 26 16:55:05 See, this won't work for those modems that send this once Aug 26 16:55:10 e.g. calypso Aug 26 16:55:14 and after sim_initialize()? Aug 26 16:55:43 And what if MBM is CORP locked? Aug 26 16:55:49 EPEV event will never arrive in that case Aug 26 16:55:54 denkenz: they send notify only after pin was ready or sim was ready or? Aug 26 16:56:23 calypso only sends ready after the PIN has been validated / skipped and the internal init has been done Aug 26 16:56:36 Until then it will fail even the IMSI checks Aug 26 16:56:47 It never sends it again Aug 26 16:56:50 and you can't query it Aug 26 16:57:48 try to read imsi (or something more exotic), if it fails, wait for calypso event? Aug 26 16:58:29 see I want to avoid a mess here Aug 26 16:58:51 Its nearly impossible, but I just want to keep it simple for the core if at all possible Aug 26 16:59:05 e.g. sim inserted -> read iccid, ecc, li, pl Aug 26 16:59:12 check pin Aug 26 16:59:25 if its ready -> wait for ack from the modem it is safe to proceed Aug 26 16:59:33 if its locked -> enter pin Aug 26 16:59:44 go back to the if its ready part Aug 26 17:00:27 The driver would have to do all the nastiness Aug 26 17:00:54 In some cases some situations simply can't be handled Aug 26 17:01:00 They don't give us enough info Aug 26 17:02:52 sim_ready_notify implies it really is safe to proceed now Aug 26 17:03:04 Not that it is safe to recheck or any other silliness Aug 26 17:03:25 and if it is not coming, should the core call some new method in order to check if sim is already ready? Aug 26 17:03:56 no, the core does nothing Aug 26 17:03:58 or should driver do the check and pass the result to core+ Aug 26 17:04:07 All it does is waits Aug 26 17:04:17 The driver has to do the right thing Aug 26 17:04:26 it can be a g_timeout_add() Aug 26 17:04:30 or an IMSI poll Aug 26 17:04:34 and what happens to the very nice 51.011 initialization order? ;-) Aug 26 17:04:52 The core does the right thing Aug 26 17:05:02 if the modem is stupid, well blame the vendor ;) Aug 26 17:06:03 coming back to the core Aug 26 17:06:38 the passwd reset +CPIN="PUK","PIN", uses the value from last CPIN? Aug 26 17:06:48 yep Aug 26 17:07:41 so is it ok to add pin type to driver and cache pin type in atmodem/sim, too Aug 26 17:08:06 or pass core pin_type to driver along with the pin type to be reset? Aug 26 17:08:26 Are you trying to support modems that support +CPIN2 or something? Aug 26 17:08:44 any modem? isimodem? Aug 26 17:09:04 I've never seen a SIM with a PUK2 provided Aug 26 17:09:21 Some modems have a vendor command to enter PIN2/PUK2 Aug 26 17:10:03 So if those modem drivers need the info to decide whether it is a PIN or PIN2, then sure, you can safely track the current password in the driver Aug 26 17:10:19 Otherwise, CPIN should work for all PUKs Aug 26 17:13:04 ok, so I leave the triggering of +CPIN: SIM PUK2 as mbm quirk Aug 26 17:19:57 Ok, I sent my proposed patch to the core Aug 26 17:30:04 there is no ready check if pin is disabled Aug 26 17:31:52 true Aug 26 17:32:06 so perhaps we need to set the ready flag on the initial pin check Aug 26 17:33:43 @@ -1391,6 +1391,7 @@ skip_efpl: Aug 26 17:33:44 DBUS_TYPE_STRING, Aug 26 17:33:44 &sim->language_prefs); Aug 26 17:33:44 Aug 26 17:33:44 + sim->flags |= SIM_FLAG_WAIT_FOR_READY; Aug 26 17:33:45 sim_pin_check(sim); Aug 26 17:33:45 } Aug 26 17:33:49 something like that... Aug 26 17:34:13 sure. and if the ready event was received before that? Aug 26 17:35:09 you need either ask for the ready event, or record it Aug 26 17:35:33 actually that won't work ... Aug 26 17:36:39 perhaps Aug 26 17:36:58 However, I'm about ready to give up on this for now Aug 26 17:37:05 The hardware is all too different Aug 26 17:41:32 Maybe we need to abandon this idea completely and try something else Aug 26 18:07:21 use check_passwd as trigger? return its results like modem_powered is done? Aug 26 18:07:51 add pin_notify()? Aug 26 18:07:53 ;) Aug 26 18:12:03 dunno, I welcome any ideas at this point Aug 26 18:12:22 The only idea I had is to quirk the entering of the CPIN like we do now Aug 26 18:12:39 and having ofono wait for sim_ready_notify when CPIN? returns 'READY' Aug 26 18:13:16 That way we can make it fireable any time Aug 26 20:45:43 ofonod[14408]: Modem: < \r\n+CIEV: 2,4\r\n Aug 26 20:45:43 ofonod[14408]: Modem: < \r\n*EPSB: 0\r\n Aug 26 20:45:43 ofonod[14408]: Modem: < \r\n*EPSB: 5\r\n Aug 26 20:45:43 ofonod[14408]: Modem: < \r\n*EPSB: 0\r\n Aug 26 20:45:45 ofonod[14408]: Modem: < \r\n*EPSB: 5\r\n Aug 26 20:45:45 If anybody cares. Aug 26 21:07:46 denkenz: pessi: I think I'm backing out of doing the ready_notify task. I am not the right person to do this -- I just don't know enough about the individual hardware quirks to be able to help make a solution that works for us. Aug 26 21:08:42 kristen: Nod no problem, it looked easy on paper ;) Aug 26 21:09:05 denkenz: yes, I thought your classification of this as C2 was optimistic :). Aug 26 22:24:43 denkenz: ok.. I got an option icon 452 usb modem. I plugged it. I restarted ofonod.. but I don't see it in list-modems Aug 26 22:26:35 is special kernel driver required? Aug 26 22:27:30 did you install ofono.rules into udev.d? Aug 26 22:27:51 derp.. I forgot to edit /etc/ofono/modem.conf Aug 26 22:29:18 modem.conf is not used Aug 26 22:29:18 what do I stick in modem.conf? What kind of modem is this thing anyway Aug 26 22:29:38 as I said, plugins/ofono.rules should be copied to /etc/udev/udev.d or whatever Aug 26 22:29:51 I eat the dogfood. Doesn't the ofono package do that? Aug 26 22:30:18 I don't know Aug 26 22:30:31 does it? Aug 26 22:30:44 I see rules.d under /etc/udev Aug 26 22:30:51 but nothing from ofon o there Aug 26 22:30:58 Then there's your problem Aug 26 22:31:35 the package installs /lib/udev/rules.d/97-ofono.rules Aug 26 22:31:35 Aug 26 22:31:40 mikeleib: the ofono install script doesn´t seem to install the udev rules in the right place. Aug 26 22:31:58 charming Aug 26 22:32:06 there's a bug for this, right? Aug 26 22:33:05 kristenc: where is the right place? Aug 26 22:33:20 incidentally, I have ofono-0.25 relase 1.4 installed Aug 26 22:33:59 mikeleib: for me it should be in /etc/udev/rules.d Aug 26 22:34:07 is that a distro dependent thing? Aug 26 22:34:17 I dunno Aug 26 22:34:20 I just put it there manually. Aug 26 22:34:41 this is for distro to solve Aug 26 22:34:48 all of them have different locations Aug 26 22:35:16 surely meego can package ofono correctly?! Aug 26 22:35:33 * kristenc doesn´t use meego for development... Aug 26 22:35:43 dogfood Aug 26 22:35:48 * mikeleib eats dogfood Aug 26 22:35:55 more power to you :) Aug 26 22:36:26 :/ Aug 26 22:36:54 googlefight is totally on the side of /etc/udev rather than /lib/udev :) Aug 26 22:37:11 there's crap in both /lib/udev and /etc/udev Aug 26 22:37:12 wtf Aug 26 22:37:20 yeah I have on my Debian system too Aug 26 22:37:24 maybe one is old and one is new Aug 26 22:37:54 so philosophically I understand the advantage of using meego whenever possible, but it is designed as a mobile, end user OS, not an OS for developers. but that is just my laziness factor coming in no doubt -- ultimately I like to just stick with what I know. Aug 26 22:38:02 I should go back to debian. At least when I run sid, I get what I diserve Aug 26 22:41:20 can I copy a file into udev.d and have udev figure it out.. do I need to restart udev? Aug 26 22:41:42 mikeleib: no, you don´t need to do anything to udev, it will find the new file. Aug 26 22:41:43 denkenz, yang_office: i need http://pastebin.ca/1926316 to build with gcc 4.3.2 Aug 26 22:42:16 * mikeleib copies for fun and profit Aug 26 22:42:39 you will need to restart ofonod though. Aug 26 22:42:54 zowy! I see a globetrotter HSUPA modem Aug 26 22:43:19 balrog-k1n: Funny, why does gcc 4.3.2 not let us do arithmetic on enums? Aug 26 22:43:38 I got a sim in there, but SimManager has no subscibernumbers Aug 26 22:44:06 denkenz: so the fix is misleading, it lets us do arithmetics but it complains about a signed/unsigned comparison Aug 26 22:44:24 len * 8 is signed apparently Aug 26 22:44:25 mikeleib: HSO does not support SIM elementary file access Aug 26 22:44:53 balrog-k1n: Hah, what about using 8u or what the syntax is Aug 26 22:45:02 and generally, you don't have to have any subscriber numbers anyway Aug 26 22:45:12 pessi already told us off for wanting that :) Aug 26 22:45:27 * mikeleib wonders if this is going to be useful to me for testing anything Aug 26 22:45:30 Robot101: And I did even earlier, but you didn't listen ;) Aug 26 22:46:14 mikeleib: What are you trying to accomplish in the first place? Aug 26 22:46:15 I've got a telephony settings applet that does forwarding, barring, tech preference, and callsettings, and the like Aug 26 22:46:25 denkenz: no this was going back a pretty long time :) Aug 26 22:46:34 as i understand it len is unsigned, but len * 8 is signed, and the enum is unsigned Aug 26 22:46:36 I'd like to test my settings applet Aug 26 22:47:00 Robot101: Dunno, I remember telling Andres not to bother with SubscriberNumbers when he was starting telepathy-yafono Aug 26 22:47:19 balrog-k1n: Yeah, 8 is signed Aug 26 22:47:26 balrog-k1n: However, you can do unsigned constants Aug 26 22:47:38 denkenz: yeah - but I think we had this discussion with Pekka for telepathy-ring before ofono existed too :) Aug 26 22:47:39 ah Aug 26 22:47:43 let me try that Aug 26 22:47:57 denkenz: ring is a little bit better than yafono ;) Aug 26 22:48:00 Robot101: Fair enough, then why did you try again? ;) Aug 26 22:48:31 denkenz: yep, if (index >= len * 8u) works too Aug 26 22:48:52 balrog-k1n: Ok just submit that then Aug 26 22:49:03 denkenz: Nokia don't like us reassigning the people who are on their projects, so the Nokia people tend to keep to the Nokia projects, and the non-Nokia people keep to non-Nokia projects - and our hive mind was offline that week :) Aug 26 22:50:32 heh, fair enough Aug 26 22:52:06 mikeleib: Your UI has to handle all these possibilities Aug 26 22:52:18 mikeleib: If SubscriberNumbers is not present, you can't set it Aug 26 22:52:33 mikeleib: This goes for all the other properties Aug 26 22:53:17 If you want ideal, phonesim is it Aug 26 22:53:33 All other ones will have issues, even the 'golden standard' mbm Aug 26 23:09:46 this is lots of work and no fun Aug 26 23:09:50 but, thanks denkenz Aug 26 23:11:32 Heh, grep for VENDOR in drivers/ and you'll realize how comparatively easy your life is ;) Aug 26 23:16:55 yang_office: How are we going with Send USSD? Is that something we can have ready soon? Aug 26 23:43:05 denkenz: was looking back over the irc log from yesterday, had a question. You say to add an 8 byte bitmap to the cache header to keep track of which blocks are present in the file, but if we read in 256 byte blocks, and we can have a max file of 64K, don´t we need 256 bits for our bitmap? Maybe you meant 8 dwords. Aug 26 23:45:03 kristenc: Yeah, 256 bit bitmap Aug 26 23:45:13 so 32 byte Aug 27 01:46:09 denkenz: I plan to send out the send ussd patch for your first round review on next Monday. **** ENDING LOGGING AT Fri Aug 27 02:59:57 2010