**** BEGIN LOGGING AT Wed Jun 16 02:59:56 2010 Jun 16 06:51:38 holtmann: ofono doesn't support cdma, right? do you know if anyone is working on that? Jun 16 06:55:46 kvalo: Right now, I don't know of anybody. Jun 16 06:56:03 Also what CDMA are you talking about? Just for Internet connectivity? Jun 16 06:56:24 That should be pretty easy to add. The full blown voice, SMS etc. CDMA is a bit trickier. Jun 16 06:57:51 I was just thinking internet connectivity Jun 16 06:58:24 I guess connman would also need changes, but they should be easy, right? Jun 16 06:59:34 No. ConnMan will not need any changes. Just the Mode property will get cdma, evdo as extra values (compared to edge, hspa etc.). Jun 16 06:59:35 All EVDO cards I know of do PPP, but you do ATD#700# or something. Jun 16 06:59:49 So for ConnMan this will all looks the same. You get an IP address and DNS servers. Jun 16 07:01:03 does cdma has an equivalent for apn? Jun 16 07:01:27 Not really. At least I don't know of any. Jun 16 07:01:36 cool. so it should be easy then Jun 16 07:02:51 I'm looking at mobile-broadband-provider-info and for cdma there seems to be usernames and passwords, nothing else. Jun 16 07:03:58 Our PPP already supports these :) Jun 16 07:06:36 but connman doesn't provide these Jun 16 09:04:12 I am trying to send / receive USSD with a modem attached on a computer Jun 16 09:04:26 I can send the USSD but I get no response to the Kermit console Jun 16 09:04:43 is there a specific AT command to set so the modem prints the output? Jun 16 09:05:25 more specifically I'd like to use the USSD push functionality so the modem would have to be in a listening loop waiting for messages Jun 16 09:05:59 right now I am just connecting to the modem on a Kermit console Jun 16 09:21:40 ruxpin: If you wanna by-pass oFono, then this is the wrong mailing list. Use the USSD interface from oFono. Jun 16 12:36:13 holtmann: i'm worried issuing AT*STKC=1 in mbmmodem/stk.c before registering for the notifications may cause a race Jun 16 12:36:41 the modem should send a *STKI directly after AT*STKC and we can't lose that one Jun 16 12:39:30 hmmm maybe it's okay because gatchat processes the notifications and responses one by one synchronously Jun 16 12:39:49 but it may need a comment in mbm_stkc_cb then Jun 16 13:13:45 balrog-k1n: That is obvious to me since everything is processed via the event loop. Jun 16 13:20:52 balrog-k1n: I am testing this right now with the f35xx hardware. Do you actually see STKI notifications. I see nothing with my card and I should get at least an update for the SIM menu. Jun 16 13:50:57 balrog-k1n: yeah, i'm receiving a "set up menu" stki Jun 16 13:51:03 oops Jun 16 13:51:05 holtmann: ^ Jun 16 13:51:54 I don't. Jun 16 13:52:31 Hold on. Now I do. Weird. Jun 16 13:59:55 balrog-k1n: Now I understand it. So on modem reset the STKI is sent once. If I stop/start ofonod, it is not send again. Jun 16 14:00:09 Can we somehow trigger that menu indication. Jun 16 14:01:36 holtmann: try *STKC=0 and *STKC=1 Jun 16 14:03:42 ofonod[5650]: Modem: > AT*STKC=0\r Jun 16 14:03:44 ofonod[5650]: Modem: < \r\nERROR\r\n Jun 16 14:04:13 how about *STKC=0,""? Jun 16 14:05:39 ofonod[5731]: Modem: > AT*STKC=0,""\r Jun 16 14:05:41 ofonod[5731]: Modem: < \r\nERROR\r\n Jun 16 14:05:43 ofonod[5731]: Modem: > AT*STKC=1,"19E1FFFF0000FF7FFF03FEFF"\r Jun 16 14:05:45 ofonod[5731]: Modem: < \r\nOK\r\n Jun 16 14:06:39 and 1,"0000000000000000"? Jun 16 14:07:23 afaik the profile download is the only way to "start" the toolkit and tell the card to send the menu Jun 16 14:08:41 Does the f36xx always sents the STKI Jun 16 14:09:43 Jeez, that is like the most round-about way of detecting a SIM I've ever known :) Jun 16 14:20:26 STKI is sent on sim initialization, probably even putting mbm into flight mode (4) won't trigger it Jun 16 14:22:18 balrog-k1n: Can we use STKE to trigger the menu setup again? Jun 16 14:24:14 holtmann: hmm, maybe sending a Menu Selection with "Go Back" or something like that would cause cards to resend the menu Jun 16 14:24:20 probably depends on the card Jun 16 14:24:43 Does your card always send the STKI? Jun 16 14:25:50 There is a SATT command on the Calypso for terminating the session Jun 16 14:25:55 Is there an equivalent on mbm? Jun 16 14:27:38 holtmann: let me check Jun 16 14:28:14 denkenz: actually Menu Selection with "End Session" or something like that should be this, i'm not sure Jun 16 14:28:32 i wonder what the calypso sends to the card when you do SATT Jun 16 14:28:52 I assume end session means one can redo the profile download Jun 16 14:29:01 but maybe that's a bad assumption Jun 16 14:29:26 on calypso it seems you can't until you send a AT+CFUN=1 again Jun 16 14:29:47 but i guess we could forge a profile download with AT+CSIM Jun 16 14:30:24 On calypso it doesn't matter Jun 16 14:30:33 we turn the modem physically off anyway Jun 16 14:30:59 However, on mbm, the 'off mode' is just flight mode Jun 16 14:31:06 so the SIM / stk are still initialized Jun 16 14:31:49 I would like to turn that modem off, but then it jumps off the bus :( Jun 16 14:31:56 exactly Jun 16 14:32:29 The best we can do is investigate whether sending a go-to-root pdu is possible Jun 16 14:32:39 Or a terminate session command Jun 16 14:35:59 holtmann: seems to always send the initial *STKI here Jun 16 14:36:12 may be the card's fault if your doesn't Jun 16 14:36:19 Hah. Mine doesn't. Stupid f35xx hardware/firmware. Jun 16 14:36:59 That card is heavily challenged anyway. EREADY? doesn't work. Only does DHCP etc. Jun 16 14:38:04 balrog-k1n: Does AT*E2SDR work for you. That is for SIM detection. Jun 16 14:38:46 We could also play with AT*E2RESET. Jun 16 14:38:56 holtmann: returns ERROR and is not listen in AT+CLAC Jun 16 14:39:01 listed Jun 16 14:39:31 AT*E2SDR=? Jun 16 14:39:31 *E2SDR: (0-1) Jun 16 14:40:01 AT*E2SDR? Jun 16 14:40:01 *E2SDR: 1,2 Jun 16 14:40:01 OK Jun 16 14:40:16 So for me that one works fine. Jun 16 14:40:58 all of these just return ERROR Jun 16 14:41:33 F3607gw Jun 16 14:43:43 seems AT+CPIN? is reliable here Jun 16 14:44:15 for the initial sim check, but it doesn't detect SIM removed later, which AT+CRSM=242 did Jun 16 14:44:23 I don't know. Using AT*E2SDR seems to be right way for f35xx cards. Jun 16 14:46:24 holtmann: after the last commit there's a reference to buf after freed Jun 16 14:47:05 Crap. Jun 16 14:47:12 Now I see why you did it this way :( Jun 16 14:47:28 i have some patches for that part in the queue Jun 16 14:48:19 I fix this up again. My bad. Jun 16 14:51:25 Pushed. Jun 16 14:54:38 balrog-k1n: Different topic. While you have the f36xx cards. Does CBS work for you? Jun 16 14:56:43 holtmann: i'll test when i have an occasion, don't have any sim right now which works on the local network that announces the station names in CBS Jun 16 14:58:07 What does AT+CSCB=0,... command say? Jun 16 14:58:14 It errors out for me on the f35xx hardware. Jun 16 14:58:34 ofonod[5972]: Modem: > AT+CSCB=0,"0-999,4352-4356"\r Jun 16 14:58:35 ofonod[5972]: Modem: < \r\n+CMS ERROR: 500\r\n Jun 16 14:58:35 ofonod[5972]: Setting Cell Broadcast topics failed Jun 16 14:59:00 AT+CSCB=0,"10,4352-4356" Jun 16 14:59:00 OK Jun 16 14:59:12 hmm Jun 16 14:59:15 AT+CSCB=0,"0-999,4352-4356" Jun 16 14:59:15 +CMS ERROR: 96 Jun 16 14:59:22 I tested MD300 in Australia and it worked fine Jun 16 14:59:38 What is wrong with my card :* Jun 16 14:59:59 Yeah, you need to AT+CSCB=1,0-65536 first Jun 16 15:00:17 AT+CSCB=? Jun 16 15:00:17 +CSCB: (0) Jun 16 15:00:17 OK Jun 16 15:00:45 That might be something we still need to play with Jun 16 15:00:48 AT+CSCB=1,"0-65535" Jun 16 15:00:48 +CMS ERROR: 302 Jun 16 15:00:55 same here Jun 16 15:01:07 Your card only supports additive, not subtractive topics Jun 16 15:01:09 { 302, "Operation not allowed" } Jun 16 15:01:19 Is the MD-300 different? Jun 16 15:01:22 balrog's card supports both Jun 16 15:01:52 I think my f35xx is really really challenged :( Jun 16 15:02:25 { 96, "Invalid mandatory information" }, Jun 16 15:02:26 i also get +CMS ERROR: 302 for AT+CSCB=1,"0-65535" Jun 16 15:02:47 lol Jun 16 15:03:20 AT+CSCB=? Jun 16 15:03:21 +CSCB: (0) Jun 16 15:03:23 Jun 16 15:03:24 OK Jun 16 15:03:31 and it seems i get +CMS ERROR: 96 when trying to enable more than 10 topics Jun 16 15:04:00 AT+CSCB=0,"4352-4361" Jun 16 15:04:00 OK Jun 16 15:04:00 AT+CSCB=0,"4351-4361" Jun 16 15:04:00 +CMS ERROR: 96 Jun 16 15:04:04 AT+CSCB=0,"10" Jun 16 15:04:04 +CMS ERROR: 500 Jun 16 15:04:07 AT+CSCB=0,"4352-4362" Jun 16 15:04:07 +CMS ERROR: 96 Jun 16 15:04:27 AT+CSCB=0,"0-9" Jun 16 15:04:27 OK Jun 16 15:04:27 AT+CSCB=0,"0-10" Jun 16 15:04:27 +CMS ERROR: 96 Jun 16 15:05:30 Yep, I'm getting the same Jun 16 15:05:37 Funny the 10 channels part Jun 16 15:06:12 why 10 is invalid while <10 is ok? Jun 16 15:06:40 My card is just fully broken when it comes to CBS support. Jun 16 15:06:50 However, I'm 100% sure my MD300 worked in Australia Jun 16 15:07:16 Of course I only sent in like 6 channels (4 ETWS & a EFcbmid and the base tower name one) Jun 16 15:07:54 The MD300 is actually older firmware than the f35xx. So funny that yours is working and mine is not. Jun 16 15:08:25 yeah go figure Jun 16 15:08:32 maybe they updated it at the factory Jun 16 15:08:47 Could be. Jun 16 15:09:24 AT+CSCB=1,".." doesn't work at all Jun 16 15:09:37 your & mine mbm doesn't support mode 1 Jun 16 15:09:44 However, there are cards that do Jun 16 15:10:26 The Qualcomm ones do, but they have other issues ;) Jun 16 15:10:35 However, the nice thing is that setting the topics to a huge list won't work Jun 16 15:10:44 The modem will puke and ofono will return an error Jun 16 15:10:49 calypso does iirc (but there's a whole lot of other issues) ;) Jun 16 15:10:52 So it should just work Jun 16 15:11:27 Qualcomm modems support cscb mode 1 too Jun 16 15:11:44 Yes, but their 0 mode is fucked. Jun 16 15:11:48 AT+CSCB=0 is supposed to add the specified channels to enabled list, right? Jun 16 15:11:52 or replace previous list? Jun 16 15:12:03 not specified in the spec Jun 16 15:12:14 General behavior is if mode=1 is supported, then mode=0 is additivie Jun 16 15:12:20 otherwise mode=0 is a replacement Jun 16 15:12:38 However, probably completely up to the manufacturer to screw up :) Jun 16 15:28:36 it's easy enough to trigger the end of session on the f3607, and it sends a *STKEND Jun 16 15:28:50 but then i can't find *any* way to re enable stk Jun 16 15:30:32 lol Jun 16 16:29:02 balrog-k1n: Try AT+CUAD Jun 16 16:29:17 Maybe that one can force SIM application reselection Jun 16 16:35:18 ofonod[13233]: Modem: < \r\n+CIEV: 1,4\r\n Jun 16 16:35:18 ofonod[13233]: Modem: < \r\n+CIEV: 1,3\r\n Jun 16 16:35:18 ofonod[13233]: Modem: < \r\n+CIEV: 1,2\r\n Jun 16 16:35:19 ofonod[13233]: Modem: < \r\n+CIEV: 1,1\r\n Jun 16 16:35:31 On the MBM these are not resulting in property changed signals for the signal strength. Jun 16 16:35:47 ofonod[13233]: Modem: > AT+CIND=?\r Jun 16 16:35:47 ofonod[13233]: Modem: < \r\n+CIND: ("battchg",(0-5)),("signal",(0-5)),("batterywarning",(0-1)),("chargerconnected",(0-1)),("service",(0-1)),("sounder",(0-1)),("message",(0-1)),("call",(0-1)),("roam",(0-1)),("smsfull",(0-1)),("callsetup",(0-3)),("callheld",(0-1))\r\n Jun 16 16:35:59 denkenz: Do we have a bug here? Jun 16 16:36:46 wtf, sounds like mbm is using index starting at 0 Jun 16 16:36:51 Instead of index starting at 1 Jun 16 16:37:12 is your card completely fucked? this was working for me Jun 16 16:37:16 *tests* Jun 16 16:38:10 ofonod[9332]: Modem: < \r\n+CIEV: 2,1\r\n Jun 16 16:38:11 ofonod[9332]: Modem: < \r\n+CIEV: 2,2\r\n Jun 16 16:38:18 {CellBroadcast} [/3534460271709900] Powered = 1 Jun 16 16:38:20 {NetworkRegistration} [/3534460271709900] Strength = 20 Jun 16 16:38:21 {NetworkRegistration} [/3534460271709900] Strength = 40 Jun 16 16:38:29 Sweet ;) Jun 16 16:38:32 Tell you what, take out your card Jun 16 16:38:36 Throw it out the window Jun 16 16:38:47 Bug fixed Jun 16 16:39:05 Here we go again. Have you any idea how much 3G hardware I have thrown out of the window by now. Jun 16 16:39:21 All of it? Jun 16 16:39:26 Yep. Jun 16 16:39:34 I don't see a problem ;) Jun 16 17:14:01 holtmann: 2 things from your review of my patch. 1) g_string_new cannot return NULL. 2) g_string_new automatically tacks on an extra 2 bytes to whatever len you specify -- would you still suggest text_len + 1? Jun 16 17:20:28 holtmann: oh, and additionally the initialization of i before calling extract_format is required the way it is written right now. Jun 16 17:20:44 since it is used as an input. Jun 16 21:36:49 kristen: g_string_sized_new(text_len + 1) sunds fine Jun 16 21:37:34 kristen: Also, please submit unit tests as well, in particular to non-global attributes like in the EMS example Jun 17 00:13:02 kristenc: If g_string_new() can not return NULL and will halt in case of OOM, then that is fine. Jun 17 00:13:31 If it allocates + 2 anyway, then of course text_len + 1 is not needed. Jun 17 00:14:19 On the other hand there is a chance that you will allocate more than text_len anyway. So it doesn't make any difference. Jun 17 00:20:02 seems this F3607gw needs the profile download to be done only after pin entry to work Jun 17 00:20:51 additionally pin entry never works at the first try because immediately after accepting pin, it returns +CPIN: SIM PIN, only a second or so later starts returning READY Jun 17 00:27:31 balrog-k1n: Yuck Jun 17 00:28:04 balrog-k1n: If you enter an invalid PIN, does it return an error or an OK? Jun 17 00:28:55 +CME ERROR: 11 Jun 17 00:29:01 and OK for valid pin Jun 17 00:31:40 11 is "SIM PIN required" Jun 17 00:44:40 However, it seems we still send a check pin after pin entry Jun 17 00:44:46 so is oFono forever confused then? Jun 17 00:45:37 it wants a PIN again, after second time it does the check again and get's a +CPIN: READY and progresses Jun 17 00:45:47 Yuck Jun 17 00:46:00 yeah Jun 17 00:46:02 Is there something we can do in the driver? Jun 17 00:46:27 we can probably remove the type of pin you just entered from the list of pins we're waiting for Jun 17 00:46:29 Perhaps using EPEV Jun 17 00:46:33 on OK Jun 17 00:47:43 I was thinking just registering to EPEV when we get an OK to +CPIN Jun 17 00:48:06 and the pin is of type PIN1 Jun 17 00:53:50 denkenz: why PIN1 only? Jun 17 00:56:19 EPEV only works for PIN1 Jun 17 00:58:38 so something like, enter_pin -> enter_pin_cb: if (mbm_quirk && pin == pin1) register(EPEV:); return else callback into the core Jun 17 01:00:29 denkenz: oh right, i only read the EPEV description not EPEE description Jun 17 01:00:58 another option is assume that the type of pin has to change after successful AT+CPIN, so poll every 100ms until it changes Jun 17 01:01:57 yuck Jun 17 01:02:10 Lets do this only after we find hardware stupid enough Jun 17 01:02:20 For now MBM tells us exactly when the pin gets unlocked Jun 17 01:02:27 No polling needed Jun 17 01:12:25 ah, the MBM also sends a +PACSP0 on both modem and data channels a moment after pin accepted Jun 17 01:12:45 not sure what this is (not in the docs) but could be used to send another AT+CPIN? Jun 17 01:19:04 That is something related to Customer Service Profile Jun 17 01:19:14 No idea wtf that is Jun 17 01:54:09 yang_office1: That reminds me, send the ussd decoder as a separate patch Jun 17 01:54:45 yang_office1: However, don't actually decode the ussd, use Andrew's stk_ussd_string structure Jun 17 01:54:58 Do the decoding in the unit test for now Jun 17 01:58:38 yay i can kind of navigate to things like "Wicked Welcomes" and "Celebs Gossip" in the stk menu Jun 17 01:59:35 sweet Jun 17 02:00:21 on a real sim I presume? Jun 17 02:01:02 yeah, the AU vodafone one seems easiest to work with as it resends the menu often just to be sure Jun 17 02:02:07 Heh Jun 17 02:30:26 denkenz: i needed to revert part of http://git.kernel.org/?p=network/ofono/ofono.git;a=commitdiff;h=f98c6dc91702c0d14c0afa2a4e32102d3105568d for envelopes to work on f36xx Jun 17 02:32:07 ok, though seems that code is equivalent Jun 17 02:32:37 it's for cases where just OK is returned, no *STKE="..." Jun 17 02:32:46 which are most cases Jun 17 02:33:10 i mean *STKE: ... Jun 17 02:33:51 Ah, because envelopes can have response data Jun 17 02:33:54 Ok I missed that Jun 17 02:34:58 or no response data in this case :) Jun 17 02:35:13 Yeah, I assumed they always send response data Jun 17 02:36:04 it should probably be: Jun 17 02:36:07 if (g_at_result_iter_next(&iter, "*STKE:")) Jun 17 02:36:19 if (g_at_result_iter_next_hexstring(&iter, &pdu, &len) == FALSE) Jun 17 02:36:26 goto error; Jun 17 02:36:29 exactly Jun 17 02:36:35 was about to say the same ;) Jun 17 02:39:30 balrog-k1n: I'd return the parse status as an out variable Jun 17 02:39:46 similar to GError, etc Jun 17 02:41:16 However, this: Jun 17 02:41:17 if (ret == FALSE) Jun 17 02:41:19 return FALSE; Jun 17 02:41:20 return TRUE; Jun 17 02:41:22 Must go, that was silly Jun 17 02:41:29 How did I allow this :) Jun 17 02:42:16 denkenz: that would work but will also need an out variable in each of the parse_ functions (lots of changes) Jun 17 02:48:09 ok fair enough Jun 17 02:48:27 Mostly I'm fine with it because the command id is required anyway Jun 17 02:49:40 in theory we could do both, set the out parameter and return non NULL response Jun 17 02:50:11 yeah, but the out parameter needs error enum + command id at minimum Jun 17 02:50:18 And probably dest / src ids Jun 17 02:50:38 oops, i mean non NULL command Jun 17 02:50:52 this is where the command id / src / dest would be passed Jun 17 02:51:43 why though? Jun 17 02:52:27 I think the point is not to have the caller g_freeing the stk_command in case of an error Jun 17 02:53:22 the caller has to call stk_command_free anyway Jun 17 02:53:42 btw. there's also an assumption in that patch that the destroy callback will not segfault if some fields of the struct have been filled in and others haven't Jun 17 02:53:56 btu that assumption was there before too Jun 17 02:54:26 I think we memset the struct, so g_free and stuff should be fine Jun 17 02:54:31 i.e. if parsing fails in the middle of the BER-TLV Jun 17 02:54:58 yeah, i briefly checked that all the destroy callbacks should work Jun 17 02:55:16 g_free should cope with null pointers, so should g_slist_foreach and g_slist_free **** ENDING LOGGING AT Thu Jun 17 02:59:56 2010