**** BEGIN LOGGING AT Tue Aug 24 02:59:57 2010 Aug 24 05:13:08 thanks Aug 24 06:10:34 zhenhua1: holtmann: I ever asked Huawei about how to use the NDIS port, and their reply was: "Yes, EM770W support NDIS port with PID 0x1404. But we don't recommand to use this feature, in Linux, the Modem interface will be the best choice." Aug 24 08:20:00 yang_office: Non-sense. Aug 24 08:20:16 Problem is just that the option driver claims the second USB interface of the device as TTY. Aug 24 08:20:49 PID is pointless btw. I would need the interface numbers. Since it is just a different interface. Not a different USB device. Aug 24 08:23:25 holtmann: which tty interface number are u using for NDIS? Aug 24 08:23:32 holtmann: are u using EM770W Aug 24 08:24:55 On my card (which is not an EM770W). It is labeled 1800 or so. It is ttyUSB1 Aug 24 08:26:31 oFono does a AT^GETPORMODE in the beginning. Aug 24 08:26:41 That tells you which interfaces are assigned to which function. Aug 24 08:26:48 i see. Aug 24 08:27:10 In general it is Modem:NDIS:DIAG:PCUI. Aug 24 08:27:14 actually i asked huawei engineers and there's no NDIS port for EM770W yet. Aug 24 08:27:17 And then the storage ones. Aug 24 08:27:49 Mine works just fine. If I cat the /dev/ttyUSB1 and ping myself remotely, I see packets coming in. Aug 24 08:28:11 Stick is from TIM in Italy for 60 EUR and it says E1800. Aug 24 08:28:12 * zhenhua1 need a modem for testing Aug 24 08:28:33 not sure if E1552 support this Aug 24 08:28:37 We have no kernel driver for the NDIS port. Aug 24 08:28:57 Run AT+CLAC and check if you see ^NDISDUP and ^DHCP. Aug 24 08:29:27 will check it later. thanks Aug 24 08:29:31 But really, we have no NDIS kernel driver for this yet. And I haven't bothered trying to fix the option driver to work properly with these cards. Aug 24 08:30:04 why we need extra driver, huawei claim their drivers are in option.c Aug 24 08:30:51 I see no net_dev in that driver? Aug 24 08:31:19 dunno Aug 24 08:31:34 Doesn't sound like the most clueful people to me. Aug 24 08:32:06 Mine is 12d1:140c. Aug 24 08:32:21 #define HUAWEI_PRODUCT_E140C 0x140C Aug 24 08:32:55 I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Aug 24 08:32:56 ekuo: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms Aug 24 08:32:56 ekuo: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Aug 24 08:32:56 ekuo: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Aug 24 08:32:56 I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Aug 24 08:32:56 ekuo: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms Aug 24 08:32:59 ekuo: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Aug 24 08:33:00 ekuo: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Aug 24 08:33:06 This is the issue. We can not tell the interfaces apart. Aug 24 08:33:16 And this is stupid from Huawei. Aug 24 08:33:32 First one is the TTY, second one is the NDIS actually. Aug 24 08:33:41 Wrongly claimed by the option driver. Aug 24 08:34:11 why not add NDIS port in ofono.rules? Aug 24 08:34:28 If the kernel still creates a TTY for it, it is pointless. Aug 24 08:34:37 The kernel needs to create a network interface for it. Aug 24 08:34:52 You can swap the order of the ports with AT^U2DIAG if you really want to. Aug 24 08:35:05 oh. i see. and i does see another EM770W has such port. Aug 24 08:35:30 No. It is still the same USB device. The interface order might be different. Aug 24 08:35:45 Run AT^GETPORMODE and compare with /proc/bus/usb/devices. Aug 24 08:35:49 if kernel create the interface, does it mean kernel support NDIS? no? Aug 24 08:35:51 AT^GETPORTMODE that is. Aug 24 08:36:17 Yes, the kernel has to take the second interface and put Ethernet or at least IP frames on it. I assume Ethernet like with MBM. Aug 24 08:36:49 okay Aug 24 08:37:07 EM770W's order should be Modem+DIAG+AT+GPS+CONTROL+NDIS Aug 24 08:37:21 but my last NDIS port is missing. Aug 24 08:37:49 one TW TME has a modem that having NDIS Aug 24 08:38:06 EM770W should also doe Voice and they are not enabling it. Aug 24 08:38:42 requires firmware upgrade and then it supports voice Aug 24 08:39:05 i remember mine should support voice call Aug 24 08:39:19 /* Don't bind network interfaces on Huawei K3765 & K4505 */ Aug 24 08:39:19 if (serial->dev->descriptor.idVendor == HUAWEI_VENDOR_ID && Aug 24 08:39:19 (serial->dev->descriptor.idProduct == HUAWEI_PRODUCT_K3765 || Aug 24 08:39:19 serial->dev->descriptor.idProduct == HUAWEI_PRODUCT_K4505) && Aug 24 08:39:20 serial->interface->cur_altsetting->desc.bInterfaceNumber == 1) Aug 24 08:39:20 return -ENODEV; Aug 24 08:39:33 Hah. So here is something. That needs to be extended for my card as well. Aug 24 08:40:04 heh, i see Aug 24 08:40:24 Not sure which one that will become the driver for this. Aug 24 08:40:55 This is all a mess. Huawei needs their own huawei.c kernel driver. The option.c is becoming a huge mess. Need to talk with Greg-KH about this. Aug 24 08:42:16 Please forward me the contact from Huawei to my Intel email address. Aug 24 08:42:24 okay Aug 24 08:45:34 forwarded Aug 24 14:24:35 balrog-k1n: I still don't understand why we need two agents? Can you please help me on this? Aug 24 14:33:03 balrog-k1n: As to the ND, this is a snippet from 31.111 section 6.4.11 about send ss: A terminal of type ND shall also ignore any icon provided together with this command. The terminal shall respond with "command performed successfully but requested icon could not be displayed" upon successful completion of the command. Aug 24 14:33:51 Does this mean we should send special response to sim? Aug 24 14:34:53 Anyway, we can always assume the terminal has display and keypad for simplicity. Aug 24 14:46:41 yang_home: There was a large discussion on IRC about the need for two agents Aug 24 14:46:57 yang_home: See if the IRC archives on nslu2 give you more insight Aug 24 14:52:30 is there a list of ofono supported devices somewhere? Aug 24 14:53:58 There isn't at this point, I'd be open to starting doc/supported-devices.txt or something Aug 24 14:54:26 However, most major families have drivers for them now, I think only sierra is missing Aug 24 14:55:53 denkenz: I have read the log roughly. One question is why the session agent is removed once the session terminates. Can we keep it alive so that the session agent and default agent can merge. Aug 24 14:56:24 Well the log discusses that question Aug 24 14:56:41 The idea is that we want them separate Aug 24 14:56:53 because different applications can be agents at different times Aug 24 14:57:01 I know it's from two different directions. Aug 24 14:57:10 e.g. Homescreen UI handling 'unsolicited' events Aug 24 14:57:18 while Settings UI handling 'user initiated' events Aug 24 14:57:52 Yes, but these agents can be alive at the same time. Aug 24 14:58:01 So they all need one service. Aug 24 14:59:04 Currently we have a lot of code to handle these two different agents, which makes the code complex. Aug 24 14:59:15 So I just wonder if we can merge this two. Aug 24 14:59:23 s/this/these Aug 24 15:00:08 Sorry, I mean these agents can't be alive at the same time. Aug 24 15:02:21 denkenz: I see. I'm not having much success with the two devices I tested: a zte and a huawei, so I was wondering if someone already tested those Aug 24 15:02:42 Anyway, we can firstly implement the features, then revisit this part to see if we really need two agents. Aug 24 15:06:22 thiago_syst: What's the type of your zte and huawei modem? And what's the problem? Aug 24 15:10:01 ZTE MF110 and huawei e226 Aug 24 15:11:04 the huawei works on some scenarios Aug 24 15:11:58 Then what's the problem with your huawei one? Aug 24 15:12:43 it doesn't work if ofonod is already running when I plug the modem Aug 24 15:13:20 Are you using the modem.conf or udev rules? Aug 24 15:13:58 I tried a patch from Kalle but it didn't work either Aug 24 15:14:24 modem.conf is empty Aug 24 15:14:50 Thus you're using udev rules. Aug 24 15:15:12 yes, the modem is detected, but I think it fails to initialize Aug 24 15:15:16 Can you get the udev notification when you plug the modem after ofonod starts. Aug 24 15:15:31 Oh, I see. Aug 24 15:15:50 Maybe you can send your at log to the mail list for further help. Aug 24 15:16:31 You may get the at log by setting the environmental variable: export OFONO_AT_DEBUG=1 Aug 24 15:17:34 I already posted this issue on the list. I sent some logs and Denis pointed me to the patch from Kalle Aug 24 15:18:15 I was supposed to send the logs with the patch applied, which I didn't so far Aug 24 15:20:34 Do you have a different log from the old one without Kalle's patch? Aug 24 15:21:02 Maybe the problem was partially fixed. Aug 24 15:23:09 I can test again with the newest code and send the logs Aug 24 15:27:56 thiago_syst: Is Kalle's patch merged to upstream. If not, I think you need to send the log with Kalle's patch applied manually by yourself. Aug 24 15:28:20 it's not upstream Aug 24 15:28:50 I'll do that, apply the patch to the latest version and send the logs to the list Aug 24 15:29:13 That might be helpful:) Aug 24 15:29:43 yang_home: Actually the agents don't necessarily exist at the same time Aug 24 15:30:29 yang_home: And the complexity from having two is actually quite small Aug 24 15:32:15 denkenz: The default agent is alive all the time, right? Aug 24 15:32:29 not necessarily Aug 24 15:33:04 But it doesn't know when there will be an proactive command comes. Aug 24 15:33:31 Sure, so it _should_ be active Aug 24 15:33:35 But it doesn't have to be Aug 24 15:34:27 And there's nothing preventing the application from registering both agents Aug 24 15:34:44 However, the separation is actually useful in some cases Aug 24 15:34:54 or we think so anyway ;) Aug 24 15:36:16 When default agent is processing some command, could we create an new session agent to handle some user initiate events? Aug 24 15:36:46 nope Aug 24 15:37:01 STK protocol is a simple request-reply Aug 24 15:37:20 No concurrency Aug 24 15:38:29 So the need of two different agents is that we need a clear way to handle different kind of events, right? Aug 24 15:43:06 More like two different interaction scenarios Aug 24 15:43:23 It allows user-initiated sessions to be done in one app Aug 24 15:43:33 vs SIM initiated sessions to be handled by the home screen Aug 24 15:44:20 ok, I can understand your points now:) Aug 24 15:44:34 I have some other concrete questions Aug 24 15:44:52 First is about ND/NK inside stk Aug 24 15:45:10 Can we always assume we have display and keypad now. Aug 24 15:45:29 I think so Aug 24 15:45:59 I think modern phone must have these _things_;) Aug 24 15:46:10 That is not really a problem right now, if it ever becomes so we can modify the agent with an extra error or two to let the core know Aug 24 15:46:40 But we cross that bridge when we come to it, if we ever come to it Aug 24 15:46:43 ok, we can handle it then if we meet such a case. Aug 24 15:48:09 Another question is about send ss command Aug 24 15:48:30 When the ME issues a successful general result for a SEND SS proactive command, it shall also include the Operation Code and Parameters included in the Return Result component from the network, as additional information. Aug 24 15:48:30 The first byte of the additional information shall be the SS Return Result Operation code, as defined in TS 24.080 [11]. Aug 24 15:48:30 The rest of the additional information shall be the SS Return Result Parameters, as defined in TS 24.080 [11]. Aug 24 15:48:44 These are snipped from the spec 31.111 Aug 24 15:49:09 Do you know what's the SS Return Result Operation code and parameters? Aug 24 15:49:24 Nope, you probably have to read 24.080 Aug 24 15:49:27 I looked at 24.080 Aug 24 15:49:45 But I couldn't understand the spec. Aug 24 15:50:28 After executing some ss command, would the network return something? Aug 24 15:51:06 The issue is that these things are handled by the modem Aug 24 15:51:14 e.g. CCFC, CCWA, etc Aug 24 15:51:40 Can we get the return data? Aug 24 15:52:04 I think the sim may need to know the returned data from network. Aug 24 15:52:10 You certainly get back the information, but you need to re-encode it back to the SIM Aug 24 15:52:25 Does Send SS have any user interaction? Aug 24 15:52:34 Nope Aug 24 15:53:05 it sends ss directly, even before showing the user the alpha id and icon Aug 24 15:53:40 So it does should alpha id and icon Aug 24 15:53:45 s/should/show Aug 24 15:54:04 yes, after send the ss. Aug 24 15:54:45 If sim wants to know the feedback from network, does it mean ofono core needs to know the feedback? Aug 24 15:55:36 I wonder if some modem doesn't talk in AT, can we get a similar feedback from network? Aug 24 15:55:51 Gah, this is nasty Aug 24 15:56:39 Anyway, I will dig into 24.080 to see what the sim wants. Aug 24 15:57:26 Do we have unit tests for terminal responses for send ss? Aug 24 15:58:06 Currently no, I will try to add some. Aug 24 15:58:26 That would be useful to know what the SIM expects Aug 24 15:58:40 And whether there's any real difference between send ss and send ussd Aug 24 16:00:31 I just checked the unit test, we have test cases for send ss and send ussd Aug 24 16:01:07 I think there is no big difference with send ss and send ussd from the point view of stk. Aug 24 16:01:28 But send ussd has two mode, MMI mode and application mode Aug 24 16:02:05 I also think the handling in oFono would be quite different. Aug 24 16:02:31 As we have some different files for ss, while only one for ussd. Aug 24 16:02:58 The sending is the same Aug 24 16:03:04 Its the response that I'm interested in Aug 24 16:04:13 ss's response has the additional information part. Aug 24 16:04:34 As I just pasted here. Aug 24 16:05:54 Yeah, so that's the tricky part Aug 24 16:07:05 For send a ss, need I first distinguish if it's call-barring, call-forwarding or call-settings, then call the different atom to send it? Aug 24 16:07:17 Well that part is done anyway Aug 24 16:07:32 Its the same code that handles SupplementaryServices.Initiate Aug 24 16:07:56 So modifying that to handle Send SS is not that hard Aug 24 16:08:34 What you need is a way to compose the results into an STK Additional Information object Aug 24 16:09:05 if (recognized_control_string(ussd, str, msg)) Aug 24 16:09:05 return NULL; Aug 24 16:09:41 What I want to do is to implement a similar function as ussd_initiate(), right? Aug 24 16:09:50 essentially Aug 24 16:10:13 ok, I'm on the right way. Aug 24 16:10:31 The last question is about sim initialization. Aug 24 16:10:42 I think we ever discussed it before. Aug 24 16:11:01 You wanted me to read EFsst. Aug 24 16:11:14 So the problem comes. Aug 24 16:12:14 Suppose we have a modem that supports gsm and wcdma. And sometimes I use it in 3G network, while the other time I use it in 2G network. Aug 24 16:12:40 When I switch from 3G to 2G, or from 2G to 3G, need we do sim initialization? Aug 24 16:13:08 a 2G sim cannot access a 3G network AFAIK Aug 24 16:13:19 I have a 3G sim Aug 24 16:13:33 In that case your SIM is always initialized as 3G if you have a 3G device Aug 24 16:13:42 or as 2G if you have a 2G device Aug 24 16:13:48 2G sim is always initialized as 2G Aug 24 16:14:15 But when i'm using 2G network. Need I use EFsst or EFust/EFest? Aug 24 16:14:55 you use the phase of the SIM Aug 24 16:14:59 network has nothing to do with it Aug 24 16:15:04 Note that the service in 2G may be different with the one in 3G. Aug 24 16:16:48 You mean if I'm always using a 3G modem with 3G sim card in a 2G network, I always rely on EFust and EFest? Aug 24 16:17:14 Could you explain me more about sim phase? Aug 24 16:17:47 Ok, so a 3G sim carries 2 sims Aug 24 16:17:55 Or really 2 SIM applications Aug 24 16:17:58 a 3G and a 2G Aug 24 16:18:07 a 2G device only knows how to access the 2G application Aug 24 16:18:11 it can never access the 3G Aug 24 16:18:16 If so, we need to rely on EFsst. Aug 24 16:18:25 In a 2G network. Aug 24 16:18:31 a 3G device will always access the 3G sim application Aug 24 16:18:39 forget about network, its only modem phase + sim phase Aug 24 16:19:35 In my case, when I'm in a 2G network, what would be my modem phase and sim phase? Aug 24 16:20:06 If your SIM provider is providing 2G sims, it will be 2G Aug 24 16:20:23 if your sim provider is providing 3G sims, it will depend on whether you're using 2G modem or a 3G modem Aug 24 16:20:36 My case is I have a 3G sim and gsm+wcdma modem. Aug 24 16:20:52 Then you will always have 3G sim phase Aug 24 16:21:28 Could I have a sim 2G+3G? Aug 24 16:22:03 If so, my case changes to: 2G+3G SIM and GSM+WCDMA modem. Aug 24 16:23:07 all 3G sims are 2G+3G Aug 24 16:23:20 that's why they work in 2G only devices Aug 24 16:23:59 denkenz: If you have a few minutes lets talk about the TEXT mode SMS part. Aug 24 16:24:09 Do we actually even wanna try to support this? Aug 24 16:24:53 denkenz: So my question is when the modem phase + sim phase change, need we do sim initialization again? Aug 24 16:25:21 yang_home: That can only happen if you remove the sim and insert it into a different modem Aug 24 16:25:28 yang_home: Or insert a different SIM Aug 24 16:25:54 holtmann: I haven't even had a chance to look yet Aug 24 16:26:11 text mode is a disaster area though Aug 24 16:26:19 I doubt they can make it work Aug 24 16:26:20 can we just select the operator to change the modem phase and sim phase? Aug 24 16:26:21 denkenz: This is more a general question to begin with. Do we wanna deal with text mode and UCS2 in text mode? Aug 24 16:27:01 yang_home: No, as I said, the radio/operator/network technology does not matter Aug 24 16:27:15 It is simply the sim type and the modem type Aug 24 16:27:28 holtmann: I personally don't Aug 24 16:27:39 Especially since they'd have to re-encode the SMS back into PDU Aug 24 16:27:49 Then the core will decode it back into text Aug 24 16:27:55 Totally pointless waste of resources Aug 24 16:30:11 And its completely insane from the manufacturer perspective not to support PDU mode Aug 24 16:30:24 Especially since it is _easier_ than text mode Aug 24 16:31:03 denkenz: If I walk from a 3G only network to a 2G only network with such case, would my phone work well? Aug 24 16:31:25 yang_home: What you don't believe me? Jeez, just think about it Aug 24 16:31:38 Does your phone suddenly re-initialize every time you switch from a 3G cell to a 2G cell? Aug 24 16:31:51 re-reading the SIM filesystem is not trivial, you would notice Aug 24 16:32:45 yes, that's also what I think about. Aug 24 16:33:36 read sim initialization procedures in 31.102 Aug 24 16:33:52 They don't talk about anything special when switching cells Aug 24 16:34:11 So your tech depends entirely on the modem and sim Aug 24 16:34:18 Test it with a Freerunner and an mbm card Aug 24 16:34:26 and a 3G sim Aug 24 16:35:16 OK, I will have some try. Aug 24 16:37:25 I just think when you walk from 3G to 2G, the modem phase + sim phase would change. And ofono would have to initilize the sim again if those 2G files haven't been read in the beginning. Aug 24 16:37:44 Trust me, you're wrong :) Aug 24 16:38:34 I'm wrong with re-reading 2G sim files? Aug 24 16:38:44 yes Aug 24 16:39:00 So ofono has to read all the 2G files and 3G files in the beginning. Aug 24 16:39:02 There's only two times you re-read sim contents Aug 24 16:39:14 When sim is inserted Aug 24 16:39:21 Or when an STK REFRESH proactive command is sent Aug 24 16:39:44 And oFono only reads one version of the files, either 3G or 2G Aug 24 16:39:55 it doesn't (and actually can't) read both versions Aug 24 16:42:02 So you hints that after I walk into the 2G network, I still use EFust and EFest, instead of EFsst. Aug 24 16:42:35 Suppose in the beginning ofono read 3G files. Aug 24 16:43:31 Do I still have some misunderstanding here:-( Aug 24 16:50:57 no Aug 24 16:51:09 3G devices can roam just fine on 2G networks Aug 24 16:51:28 You don't need to re-initialize the SIM every time you recamp to a different cell Aug 24 16:51:46 I think you're just being paranoid and lacking details Aug 24 16:52:32 Maybe I'm too sleepy now. I will think about it tomorrow. Aug 24 16:52:56 3G device + 3G sim -> EFust and EFest, simple as that Aug 24 16:53:08 2G device + 3G sim -> EFsst Aug 24 16:56:13 There must be something wrong with me, but my case is 3G+2G device. Aug 24 16:57:41 heh, all 3G devices are "3G + 2G" Aug 24 16:58:34 Then oFono would not read EFsst at any time. Aug 24 16:58:43 exactly Aug 24 16:59:02 Unless you put in a 2G sim Aug 24 16:59:25 That means even if I'm in 2G network, oFono can't use EFsst. Suppose I don't change the sim Aug 24 17:00:45 Again, 3G devices are backward compatible with 2G networks Aug 24 17:02:22 Think of it this way, USB 1.1 -> USB 2.0 compatible PC -> they talk 1.1 Aug 24 17:02:25 Oh, maybe my problem is about the understanding on EFsst. Aug 24 17:02:31 USB 2.0 -> USB 1.1 PC -> they talk 1.1 Aug 24 17:02:37 USB 2.0 -> USB 2.0 -> they talk 2.0 Aug 24 17:02:41 Same here Aug 24 17:03:32 EFsst is simply the predecessor to EFust & EFest Aug 24 17:03:48 There are plenty of cases like this, look at EFecc between 11.11 & 31.102 Aug 24 17:04:00 You'll notice significant differences Aug 24 17:14:25 I originally think EFsst indicates the service available in 2G network, and you have to rely on it when you're in 2G network. Aug 24 17:15:38 That would be my problem Aug 24 17:18:28 denkenz: Really thanks for your patient explanation. Aug 24 17:18:48 no problem :) Aug 24 18:30:54 yang_office: my original implementation allowed any number of agents, all receiving the same requests and i still think it's the simplest and most robust way, so i can't be blamed for the current shape of the api :) Aug 24 20:45:43 denkenz: I am trying to use the mbm modem for debugging, but having some issues with it. I added some lines to modem.conf, but list-modems does not show it. Is there something else I'm supposed to do? Aug 24 21:02:53 kristen: mbm should be auto-detected by udev Aug 24 21:06:24 denkenz: ok, so does that mean that I have to use something like connman to verify it works, or can I use just a test script of some kind? Aug 24 21:06:42 No, it just means you may have built without udev support? Aug 24 21:07:08 Or that ofono.rules are not installed in udev.d properly Aug 24 21:07:57 list-modems / monitor-ofono are enough for this Aug 24 21:08:04 connman just listens to the same signals anyway Aug 24 21:08:28 hum... well, it looks like I have to deliberately disable udev. I didn't pass anything special to configure for that. Aug 24 21:08:33 * kristen checks rules Aug 24 21:09:09 disabling udev is a bad idea Aug 24 21:09:17 right - I don't do that :). Aug 24 21:09:39 Make sure you have udev -dev package Aug 24 21:09:46 but more likely the culprit is ofono.rules Aug 24 21:09:52 there is no ofono.rules in /etc/udev/rules.d Aug 24 21:10:00 so that is indeed the problem. Aug 24 21:13:25 It is impossible to disable udev actually. Aug 24 21:13:50 Does it fail these days? Aug 24 21:13:58 kristen: Just copy the file in there. udev does auto-reload with inotify. Then re-plug the dongle. Aug 24 21:14:09 denkenz: Nope MBM detection just works fine. Aug 24 21:14:17 you still have if UDEV in Makefile.am Aug 24 21:14:52 denkenz: Hah. That needs to be changed to mandatory. Aug 24 21:14:59 Distro without udev is rather useless. Aug 24 21:15:23 I know we decided that, but didn't know if you made the changes Aug 24 21:15:30 configure.ac still refers to --disable-udev Aug 24 21:15:49 Yeah, but default this is all on. You can only manually shrink the number of plugins. Aug 24 21:16:45 ok, that works better. Aug 24 21:17:12 good Aug 24 21:17:31 kristen: Only phonesim should need modem.conf. Everything else would be a bug. Aug 24 21:17:47 yes, we still need to remove atgen Aug 24 21:18:10 We get there eventually. Aug 24 21:18:52 so if I want to force mbm to go through it's sim initialization path, which script will do that for me? Aug 24 21:19:05 enable-modem Aug 24 21:19:35 cool, thank you. Aug 24 21:26:46 well, I don't think I made the right changes in the driver, but I sent it off to the list anyway so you can take a look. Aug 24 21:28:39 kristen: For mbm driver, see drivers/atmodem/sim.c and look for the VENDOR_MBM Aug 24 21:28:55 That EPEV notification should trigger ofono_sim_ready() Aug 24 21:29:12 ok Aug 24 21:32:17 For the core changes, the logic is a bit more tricky because there can be several pins Aug 24 21:33:08 e.g. a SIM PIN and a Provider PIN Aug 24 21:33:47 so to be on the safe side, you need to set the flag only when EnterPin("pin") is called and succeeds Aug 24 21:34:01 Or when ResetPin(puk) is called and succeeds Aug 24 21:36:06 not sure I understand - so the driver should only call ready_notify when EnterPin or ResetPin succeeds? Or the core should only set the new status flag I made to SIM_STATUS_READY if both notify_ready() is called AND enter_pin() or reset_pin() suceeds? Aug 24 21:36:26 So here's a possible scenario Aug 24 21:36:40 You have a SIM with a PIN set, and your phone is carrier locked Aug 24 21:37:07 Suppose the SIM you're putting in is not native to your phone Aug 24 21:37:26 The first thing is you will be asked for a SIM PIN Aug 24 21:37:38 Because until that is provided, SIM is encrypted and can't be used Aug 24 21:38:04 Once you provide the PIN, the SIM becomes useable and the IMSI / carrier information can be read Aug 24 21:38:13 At that point your phone will ask you for _another_ PIN Aug 24 21:38:43 The sim_ready notification is only relevant to the first SIM PIN, not the carrier lock Aug 24 21:39:49 Or at least that's how I interpret it today, given that these notifications arrive once only Aug 24 21:40:13 We can't expect the driver to call sim_ready for every PIN asked Aug 24 21:42:10 balrog-k1n: Around? Aug 24 21:42:46 balrog-k1n: Do you remember if it is ResetPin("puk", "111..", "1111") or ResetPin("pin", "111..", "1111")? Aug 24 21:46:34 denkenz: sorry, I'm still making sure I understand you. Are you telling me that you want me to add an additional status, or that you think I've put the check for ready in the wrong place? The way I think it works is that once the driver calls ready_notify() once, subsequent calls to do anything to the pin will be already marked as "ready" so will not cause the driver to need to call ready_notify again. Aug 24 21:47:30 So, just a sequence of events Aug 24 21:47:35 CPIN? -> PIN Aug 24 21:47:46 or maybe you are saying I need a second status, because you want another delay? Aug 24 21:48:00 enter_pin -> success Aug 24 21:48:08 wait for sim_ready Aug 24 21:48:12 sim ready arrives Aug 24 21:48:20 CPIN? -> "CORPPIN" Aug 24 21:48:28 enter_pin -> success Aug 24 21:48:31 wait for sim ready Aug 24 21:48:46 and now you're stuck, because most modems only provide sim_ready for the first PIN Aug 24 21:48:55 The other PINs are all simulated on the modem firmware Aug 24 21:49:43 I think we should rename sim_ready_notify to something else, because we have set_sim_ready and ofono_sim_ready which are different than ofono_sim_ready_notify(). When you say wait for sim_ready, are you talking about ofono_sim_ready, or ofono_sim_ready_notify? Aug 24 21:50:10 Sorry, ofono_sim_ready_notify Aug 24 21:50:18 The function your patch provides Aug 24 21:51:01 Basically we should only wait for ofono_sim_ready_notify if the PIN being asked for is "pin" or "puk" Aug 24 21:51:23 For all others, leave the current behavior of immediately re-checking Aug 24 21:53:18 ok - I think the basic problem is that I don't even call query_password_state (and this causes CPIN? to be send, right?) unless ofono_sim_ready_notify() has been called. It sounds to me like you are saying that the check for SIM_STATUS_READY is in the wrong place, that it should be *after* we query password, but before anything else. Aug 24 21:54:15 (and only for pin or puk). Aug 24 21:55:25 Lets put it this way, your patch works as intended, I just want it to be more explicit Aug 24 21:55:52 is the "at_send_flash()" atmodem/voicecall.c only for a CDMA modem? Aug 24 21:55:54 * kristen struggles to get a straight answer Aug 24 21:56:41 ok, I will make another attempt, although I'm not entirely sure what you are saying. We'll see. Aug 24 21:56:45 + if (!(sim->status & SIM_STATUS_READY)) { Aug 24 21:56:46 + sim->status |= SIM_STATUS_WAITING_FOR_PIN; Aug 24 21:56:46 + return; Aug 24 21:56:46 + } Aug 24 21:56:47 + Aug 24 21:56:47 + if (sim->status & SIM_STATUS_WAITING_FOR_PIN) Aug 24 21:56:47 + sim->status &= ~(SIM_STATUS_WAITING_FOR_PIN); Aug 24 21:56:47 + Aug 24 21:57:11 So you set SIM_STATUS_WAITING_FOR_PIN only if SIM_STATUS_READY flag is not set Aug 24 21:57:22 And you set SIM_STATUS_READY in the _notify() Aug 24 21:57:37 right . Aug 24 21:57:38 This works, but you really have to think about it Aug 24 21:57:59 I'd rather see something like if (pin == OFONO_PIN_TYPE_PIN) Aug 24 21:58:06 flag |= wait_for_ready Aug 24 21:58:10 my thought was that if you got to check_pin and you weren't ready, you mark that you are waiting. Then when ready_notify is called, you check to see if we are waiting. Aug 24 21:59:12 Yeah, but you can easily do that by checking sim->pin_type == NONE Aug 24 21:59:21 If that's the case, ignore _notify() Aug 24 22:00:08 See what I mean? Aug 24 22:00:15 Its just about readability Aug 24 22:01:04 by ignore _notify() you mean, in ofono_sim_ready_notify() don't bother to call check_pin? Aug 24 22:01:40 Yeah, if we are past the pin check and the modem driver is acting irrationally Aug 24 22:01:47 Then just sanitize it Aug 24 22:02:17 alt-route: I have no idea what you're talking about Aug 24 22:46:06 denkenz: if drivers/atmodem sends CPIN? and the sim is not ready yet, will you get an error returned in crsm_pin_cb? Aug 24 22:46:51 probably, it sort of depends on the hardware Aug 24 22:47:19 so, is sending CPIN? the only way to determine the pin_type? Aug 24 22:51:25 you had suggested we only wait for ready for certain pin types, but if we have to have a successful callback from query_password for us to know what the pin_type is, then that is not going to be possible. Aug 24 22:54:02 heh Aug 24 22:54:30 You're digressing into a slightly different issue Aug 24 22:54:40