**** BEGIN LOGGING AT Tue Nov 09 02:59:58 2010 Nov 09 10:01:37 should ofono detect cinterion tc-65 correctly with udev via usb-to-serial cable? Nov 09 13:41:39 hbragge: Most likely not Nov 09 13:42:31 And there's no cinterion driver anyway, so someone has to write one first Nov 09 13:54:06 hmm i've been using atgen with the ofono version that still has modem.conf Nov 09 13:54:43 but i'm out of ideas how to configure that to work with udev Nov 09 14:00:05 or is it even possible via (usb-to-)rs232 Nov 09 14:08:54 hbragge: modemconf was deprecated, you can pretty much do everything it did with a custom driver and udev Nov 09 14:09:42 hbragge: See the wavecom plugin as an example Nov 09 14:13:05 hmm okay Nov 09 14:13:12 thanks for the pointer Nov 09 14:14:57 Then simply add something like KERNEL=="ttyUSBx", ENV{OFONO_DRIVER}="cinterion" Nov 09 14:15:04 to the udev rules Nov 09 14:16:13 With some more magic you can even rewrite the USB->Serial converter nodes to have any name you wish to make this even easier Nov 09 14:23:04 hope i didnt need to write my own plugin just to define serial parameters Nov 09 14:23:17 but maybe i'll give it a try Nov 09 14:26:04 It doesn't matter, even the wavecom plugin has to modify the behavior Nov 09 14:26:21 And if you want proper modem integration, the atgen plugin is not enough Nov 09 14:27:22 So yes, its a bit painful, but there simply isn't a modem that is 100% 27.007 compliant Nov 09 14:33:41 ok think you're right Nov 09 17:32:01 denkenz: have you had time to look into sim_ready_notify patches? Nov 09 17:33:57 pessi: I have, I still don't like them ;) Nov 09 17:36:03 there is still the problem if the ready indication is missed, like modem is initiaalized before ofono Nov 09 17:36:44 This has to be handled by the driver Nov 09 17:36:53 even SIM busy error checking in the core isn't acceptable Nov 09 17:36:56 yes, the problem isin atmodem driver Nov 09 17:37:06 we have to run a CRSM before we even check the PIN Nov 09 17:37:33 So the driver _has_ to make sure that CRSM can be run when ofono_sim_inserted_notify is set to TRUE Nov 09 17:37:44 Unless the firmware is just braindead Nov 09 17:37:46 zte runs crsm fine even when cpin returns cme 14 Nov 09 17:39:23 So the busy hack is trying to take care of the race between CPIN? returning busy and CPIN? returning SIM PIN? Nov 09 17:40:05 ..or CPIN? returning READY Nov 09 17:42:24 pessi: But then we still don't handle the pin / puk case Nov 09 17:42:45 You still need to set the ready flag when user enters the pin / puk Nov 09 17:43:07 uh, like, locking sim because too many pin change/lock/unlock attemtps? Nov 09 17:43:25 No, like on sane hardware that returns CPIN? -> SIM PIN right away Nov 09 17:43:30 without doing the sim busy crap Nov 09 17:44:34 you meanwe trust blindly AT+CPIN="xyzzy" -> OK At+CPIN? -> READY ? Nov 09 17:45:00 so I think there are two possibilities Nov 09 17:45:04 ..unless we have quirk? Nov 09 17:45:12 AT+CPIN? -> CME ERROR: 14 Nov 09 17:45:15 ... Nov 09 17:45:20 sim_ready() Nov 09 17:45:27 AT+CPIN? -> READY Nov 09 17:45:30 or Nov 09 17:45:36 AT+CPIN? -> SIM PIN Nov 09 17:45:43 AT+CPIN="1234" Nov 09 17:45:47 .... Nov 09 17:45:49 sim_ready() Nov 09 17:45:53 AT+CPIN? -> READY Nov 09 17:45:54 or Nov 09 17:46:02 AT+CPIN? -> CME ERROR: 14 Nov 09 17:46:03 ... Nov 09 17:46:05 sim_ready() Nov 09 17:46:08 AT+CPIN? -> SIM PIN Nov 09 17:46:17 AT+CPIN="1234" Nov 09 17:46:18 ... Nov 09 17:46:20 sim_ready() Nov 09 17:47:12 So you cover the first case and part of the third case Nov 09 17:47:16 But not the second case Nov 09 17:47:46 admittedly my original patch did not cover the 1st case, but then I still think the driver needs to do this Nov 09 17:48:52 second case is covered by CALLBACK_WITH_SIM_BUSY Nov 09 17:50:05 it should probably be moved into at_pin_query() Nov 09 17:50:24 Yeah, see I don't like us messing with errors like that Nov 09 17:51:15 like errors having some meaningful content? Nov 09 17:51:32 As in fabricating errors Nov 09 17:51:43 Honestly I can deal with error 14 checking in the core Nov 09 17:51:57 But I think the wait_for_ready flag should be set on enter_pin / enter_puk Nov 09 17:54:30 but then we have the problem where ofono is too fast, it gets READY from CPIN? but modem is still initializing and CRSM fails Nov 09 17:55:41 we can check CRSM success in atmodem sim driver Nov 09 17:56:04 but the problem is selecting a good ef id Nov 09 18:00:21 on N900, i used EFad but Jukka says it is the first thing modem reads from the SIM after PIN check succeeds Nov 09 18:06:30 EFad is PIN protected yes Nov 09 18:07:05 This is why I want to keep this out of the core Nov 09 18:07:28 The modem driver can play whatever dirty tricks relevant to the weirdness of the particular firmware Nov 09 18:09:05 ideally I want something like ofono_sim_inserted_notify -> We're ready for PIN query and CRSM must be able to succeed Nov 09 18:09:45 ofono_sim_ready_notify -> CPIN query must return READY and all further sim reads (including phonebook and sms) must be able to succeed Nov 09 18:18:07 so now only problem is when core wais for ofono_sim_ready_notify(), like, only after query_password returns PIN or PUK and we enter PIN or PUK ... or if query_password returns xyzzy, where xyzzy is CME 14 or NOT_READY or something Nov 09 18:19:34 CME 14 should not happen Nov 09 18:20:02 Because then we have to overload the meaning of ofono_sim_ready_notify to also mean "Oh its safe to query CPIN now" Nov 09 18:20:19 To me, that's the contract of ofono_sim_inserted_notify Nov 09 18:21:32 but it already means "Oh its safe to query CPIN now" Nov 09 18:22:36 Not if we get CME: 14 ;) Nov 09 18:23:10 and it means "wait for further notify" Nov 09 18:23:35 No, the way to do this properly is to have the core wait no matter what Nov 09 18:23:50 Then if the hardware is too stupid to tell us when it is ready, then the driver has to poll Nov 09 18:27:29 The atmodem driver can just run a +CIMI +CPBS +CPMS poll Nov 09 18:27:42 Once all three succeed it is pretty much safe to say that the sim is ready Nov 09 18:29:10 the core should be able to tell driver that it is waiting for notify.. I think it is done quite nicely with response to query_password Nov 09 18:29:25 either error code or special passowrd enum or extra parameter Nov 09 18:30:25 extra parameter to callback like wait_for_notify Nov 09 18:31:27 (oh, so it is the driver telling that notify is pending) Nov 09 18:31:49 sorry, not following Nov 09 18:32:37 I'm still taliking about the case where the pin is disabled.. so driver checks it can do CPIN? and CRSM and says insert_notify Nov 09 18:32:47 Ah ok Nov 09 18:33:00 But the problem there is that the sim driver doesn't know this info either Nov 09 18:33:13 only the modem driver does Nov 09 18:33:36 ....but the modem is still initilizing the SIM and it will notify driver later Nov 09 18:34:31 So lets map out the cases again: Nov 09 18:34:44 1. CPIN? -> READY and all subsequent requests are fine Nov 09 18:34:58 2. CPIN? -> READY, but a race on whether the modem is really ready Nov 09 18:35:47 denkenz: phonesim -gui is supposed to start a gui, right? Nov 09 18:35:54 3. CPIN? -> SIM PIN, +CPIN="1234", [optional unsolicited notification], CPIN? -> READY Nov 09 18:35:58 padovan: yep Nov 09 18:36:05 padovan: Once you enable the modem Nov 09 18:36:42 4. CPIN? -> CME 14, CPIN? -> SIM PIN, +CPIN=1234", [optional unsolicited notification], CPIN? -> READY Nov 09 18:37:22 Which ones am I missing? Nov 09 18:37:42 that sounds pretty complete Nov 09 18:37:56 So the core has no idea about case 1 or 2 Nov 09 18:38:04 Only the modem driver knows Nov 09 18:38:25 So it is up to the modem driver to figure this out Nov 09 18:39:18 Strictly speaking we can set the wait_for_ready flag on a SIM PIN, SIM PUK or the first cpin query Nov 09 18:39:31 denkenz: and filename shall passed right? Nov 09 18:39:32 (if it returns READY) Nov 09 18:39:43 padovan: Yep, its in the HACKING document actually Nov 09 18:40:15 oh, sorry Nov 09 18:40:37 But even if we have the core wait, the driver still has to make that decision... Nov 09 18:40:51 So that is actually nasty Nov 09 18:41:43 However, we have similar issues with STK as well Nov 09 18:42:00 the case 2 is most evil one Nov 09 18:42:02 If the modem can be left in offline state while oFono is restarted, we lose the STK functionality anyway Nov 09 18:42:26 Case 2 cannot be solved without major hacking or a proper sim reset Nov 09 18:43:57 and if we leave it to modem driver, they have to grow the same notification support and probably ef reading as the sim driver already has Nov 09 18:44:16 why do you need EF reading? Nov 09 18:44:22 denkenz: stk needs some indication from SIM, you just cannot poll it? Nov 09 18:44:43 pessi: No, STK needs profile download and the initial setup menu command Nov 09 18:44:51 That is done once Nov 09 18:45:03 If you leave the modem on while you restart oFono, you're screwed Nov 09 18:45:08 for the case where we get the notifiction but the notification has already been sent Nov 09 18:45:40 ..s o you cannot support stk on modems that you cannot reset? Nov 09 18:45:52 ...silently, of course... Nov 09 18:46:29 Nope, not without sending a reset and having it disappear off the bus Nov 09 18:46:36 We have this issue on mbm today Nov 09 18:46:50 STK works when you first plug it in, if you restart oFono you're screwed Nov 09 18:47:11 the SIM never sends the setup menu again, and the modem doesn't cache it Nov 09 18:48:19 Most of these manufacturers never considered these cases Nov 09 18:48:47 But then most can't follow 3GPP standards either ;) Nov 09 18:50:14 so how do you plan to do silent reset? take modem off the (d-bus) and then make a fresh start, except CPIN? returns READY? Nov 09 18:50:39 silent reset is for the firmware crashing Nov 09 18:50:55 yes Nov 09 18:50:56 It still leaves the SIM in a 'hot' state Nov 09 18:51:17 Unless of course it is just magic to remember the PIN Nov 09 18:51:39 uh-oh, so you cannot use it to re-init stk?? Nov 09 18:52:14 I don't think so Nov 09 18:52:21 I think sim reset request from stk did not lose pin Nov 09 18:52:52 Oh, the modem *can* reset the SIM session, but that is done after the PIN AFAIK Nov 09 18:53:09 So for STK we potentially can fix it Nov 09 18:53:18 But it is still up to the modem to do the right thing Nov 09 18:53:42 I don't have enough details of how silent resets work on real hardware Nov 09 18:53:57 From my basic understanding the firmware crashes, but the sim is left hot Nov 09 18:54:05 But maybe I'm completely wrong Nov 09 18:54:31 somehow the sim has re-synchronize with modem Nov 09 18:54:42 ..to.. Nov 09 18:55:04 So I suspect that the SIM session is reset Nov 09 18:55:21 But that is done after the application is selected, which is only available after SIM PIN has been accepted Nov 09 18:58:19 But again, this is only available on 'proper' modems Nov 09 18:58:28 Not the crap you get from zte/huawei/etc ;) Nov 09 18:59:47 denkenz: Are you ok with the reset button in SIM -> Card? Nov 09 19:00:38 padovan: Yeah that's fine Nov 09 19:01:47 I just have to figure out how now, I never played with Qt or C++ ;) Nov 09 19:01:55 It should be easy. Nov 09 19:02:29 Qt4 designer is your friend :) Nov 09 19:03:51 QtCreator is your friend Nov 09 19:05:10 a friend that suddenly leaves for no random reason sometimes when you touch it Nov 09 19:06:19 Well, designer doesn't leave at least ;) Nov 09 19:10:17 pessi: On which modems are we seeing the case 2 behavior? Huawei & zte? Nov 09 19:11:55 xti, isi Nov 09 19:12:17 I think mbm does polling in init, or at least my patch does Nov 09 19:13:14 xti? Nov 09 19:13:28 ifx Nov 09 19:14:24 mbm even? hm Nov 09 19:15:47 but we poll CPIN in the driver for that one Nov 09 19:16:19 yep, poll mbm and CPIN? returns different errors, but you can also wait for *epev Nov 09 19:16:55 But *EPEV only comes once and you can never query it Nov 09 19:17:32 of course, you mostly miss it unless you have mbm at the end of usb cable and ofono is ready when you insert the cable Nov 09 19:18:06 looking from the driver ifx is much nicer Nov 09 19:18:09 actually I think mbm only sends it if the PIN check is required Nov 09 19:18:21 It doesn't send it if the pin is unlocked Nov 09 19:21:10 I had my mbm on PCI express converter with external USB cable and it sent *EPEV if PIN was unlocked Nov 09 19:21:32 Ok fair enough Nov 09 19:22:39 However, I think STE doesn't have a race condition Nov 09 19:22:45 or MBM rather Nov 09 19:23:03 Once it returns EPEV it is actually ready Nov 09 19:23:30 So even if we restart oFono, there should be no problems Nov 09 19:25:08 So do you have at trace logs of these problems? Nov 09 19:27:27 on isimodem? Nov 09 19:28:16 there are plenty, but I can try to see what happens mbm Nov 09 19:28:36 zte is happy if it gets a chance to retry after cme error 14 Nov 09 19:30:07 hm, I'm pretty sure that setting wait_for_ready flag for sim pin & sim puk would work alright Nov 09 19:30:14 This leaves the unlocked case Nov 09 19:32:42 yep. but I'll have to go now Nov 09 20:27:31 denkenz: I added the Reset button, check if it is right. Nov 09 20:27:45 It was my first try in C++ ever :) Nov 09 20:32:54 let me look Nov 09 20:35:20 So the only problem is this is not related to the SIM Nov 09 20:35:28 It is actually a modem firmware crash Nov 09 20:35:51 Perhaps just adding a 'Modem' tab with a reset button is better Nov 09 20:37:46 You said here that it was fine there :) Nov 09 20:37:53 I'll change, no problem Nov 09 20:39:41 sorry I must have thought something else Nov 10 01:43:32 anyone here have experience for using Huawei 3G module for ofono ? **** ENDING LOGGING AT Wed Nov 10 02:59:57 2010