**** BEGIN LOGGING AT Fri Jun 04 02:59:57 2010 Jun 04 03:36:06 It doesn't matter, its what the network advertises Jun 04 03:39:46 kvalod: Can you tell me the idProduct of the E1552? Jun 04 03:39:56 kvalo: ^^^^ Jun 04 03:45:50 holtmann: Do you know whether the de-qcdm magic might work on the Huawei modems? Jun 04 03:46:40 my thinking is that we need two different paths otherwise, since the E160G I have is sane... Jun 04 04:25:14 denkenz is gone, but my huawei e1552 has id 12d1:1001 after usb-modemswitch. lsusb says that's the id for huawei e620 Jun 04 04:27:16 07:25 < kvalo> denkenz is gone, but my huawei e1552 has id 12d1:1001 after usb-modemswitch. lsusb says that's the id for huawei e620 Jun 04 04:28:52 denkenz: and no complaints about having a database of all modems in the rules, if you think that's the only option. but what if two modems have same id but work differently? Jun 04 04:30:59 kvalo: I have yet to see that Jun 04 04:31:32 ok Jun 04 04:31:51 kvalo: I peeked at the wader udev.rules and they cover ~25 models with 5 udev rules Jun 04 04:32:08 wader? Jun 04 04:32:28 wader-core, another ModemManager competitor Jun 04 04:32:44 oh, haven't heard about that one Jun 04 04:33:28 cool Jun 04 04:33:28 Here's a rule for your device: Jun 04 04:33:30 # Generic 0x1001 Jun 04 04:33:31 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1001", ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_TYPE_MODEM}="1" Jun 04 04:33:33 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1001", ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_PORT_TYPE_AUX}="1" Jun 04 04:34:44 I can test later today with my modem. it's early morning now Jun 04 04:35:57 nod, I'm still worried about how to handle the weird huawei event-only tty Jun 04 04:36:24 can you peek into holtmann's novatel driver and see if you can use the same qcdm magic on the huawei? Jun 04 04:36:33 probably not, but worth a shot Jun 04 04:36:57 I'll add it to my (long) todo list :) Jun 04 04:38:03 ah nevermind, that uses some other magic Jun 04 04:38:41 ok Jun 04 07:59:16 good morning. I'd like to get my option modem to report which technology currently is used Jun 04 08:00:05 looking through the code I found some interesting places to start with Jun 04 08:00:53 I understand that the option modems do not report the information with the COPS commands Jun 04 08:01:14 instead the OSSY & co commands have to be used Jun 04 08:03:29 Do I have to add some hooks to COPS code to trigger the option related code? Jun 04 08:03:38 doesn't seem to be the right way to do it Jun 04 08:37:24 wagi: if the syntax is similar to COPS then you could probably add a vendor quirk in the atmodem driver Jun 04 08:38:32 if it's a completely different command then a separate netreg driver (perhaps similar to atmodem/network-registration.c) would be in order Jun 04 08:58:04 balrog-k1n: If I understand the current code corectly, COPS is called and the modem reports things back but not the 'tech' Jun 04 08:59:03 balrog-k1n: and what happends than is ofono_netreq_status_notify(...,0) will be called Jun 04 08:59:21 and this overwrites any tech settings Jun 04 09:00:02 so if COPS should be called toghether with OCTI then the result has to be merged somehow Jun 04 09:00:35 I'll try to understand how the quirks are supposed to work Jun 04 09:00:40 thanks anyway for the tip! :) Jun 04 10:07:57 padovan: not sure when will u submit DUN client patches again. Jun 04 10:08:20 padovan: assume you have got comments from the mailing list. Jun 04 10:12:37 zhenhua: I'll resend the bluetooth.c part today I think, then I have to rework the DUN part. Jun 04 10:14:55 DUN emulator? Jun 04 10:16:18 tmzt: DUN client. Jun 04 10:16:59 padovan: how is it going with the dun client? Jun 04 10:19:15 padovan: thanks. Jun 04 10:19:39 tmzt: DUN emulator is server side that i am working on. Jun 04 10:19:57 how is that progress? Jun 04 10:21:57 kvalo: I'm working on the BlueZ part for the DUN client, I have also the rethink the oFono part since it will be a separated daemon. Jun 04 10:24:57 padovan: yeah, I read about the separate process. I'm just eagerly waiting for dun client support :) Jun 04 14:12:09 wagi: Follow the mbm quirk in netreg driver Jun 04 14:12:30 wagi: Most of the crumbs for HSO are already there Jun 04 14:39:10 denkenz: yups, I'm follow the mbm quirk Jun 04 14:39:24 denkenz: I should be able to send something today Jun 04 14:39:47 denkenz: but I don't think it's good enough Jun 04 14:39:58 denkenz: at least we can talk about it then :) Jun 04 14:40:23 nod, theres one obscure command missing afaik Jun 04 14:40:37 see modem manager for details Jun 04 14:40:50 you mean ouwcti? Jun 04 14:41:12 there isn't much documentation around Jun 04 14:41:25 I only found a discussion on this mailing list between you and marcel Jun 04 14:43:07 yeah that one Jun 04 14:43:12 or something related Jun 04 14:43:23 I think there's a magic command to enable owcti unsolicited Jun 04 14:44:09 I get those owcti Jun 04 14:44:54 according to MM: OSSYSI gives you 0: GRPS (details in octi), 2: UMTS (details in owcti) Jun 04 14:45:13 OCTI 1: GSM, 2: GPRS, 3: EDGE Jun 04 14:45:34 OWCTI 1: UMTS, 2: HSDPA, 3: HSUPA, 4: HSPA Jun 04 14:45:57 though I saw also an OSSYSI 3 Jun 04 14:46:04 don't know what that means Jun 04 14:46:43 I think OSSYSI reports network cell mode Jun 04 14:48:05 Its been a while, but to me OSSYSI was useless Jun 04 14:48:23 you either query OCTI/OWCTI on a CREG or rely on them unsolicited Jun 04 14:50:26 let me send the patch I'm working on. I'm debuging it with the led info from the usb stick. it's seems to match Jun 04 14:50:54 nod, I've an Option 451 & 452 here, so I can test Jun 04 14:51:15 cool Jun 04 14:51:25 but be warned, the patch isn't that great Jun 04 15:02:19 denkenz: having those HSO hacks in the generic atmodem part seems a bit weird Jun 04 15:03:05 denkenz: on the other hand maintaining a complete network-register.c implementation might also just be overkill Jun 04 15:04:10 wagi: exactly Jun 04 15:06:10 wagi: Why the hacks in the core? Jun 04 15:07:47 also Jun 04 15:07:48 + if ((status == 1 || status == 5) && tech == -1) { Jun 04 15:07:50 + switch (nd->vendor) { Jun 04 15:07:51 + case OFONO_VENDOR_OPTION_HSO: Jun 04 15:07:53 + tech = option_octi_owcti_to_tech(nd); Jun 04 15:07:54 + default: Jun 04 15:07:56 + tech = nd->tech; Jun 04 15:07:57 + } Jun 04 15:07:59 + } Jun 04 15:08:00 You might as well call option_octi_owcti_to_tech elsewhere Jun 04 15:08:28 denkenz: I wanted to notify the core but didn't have the rest of the arguments for _status_notify Jun 04 15:08:41 denkenz: and then I would overwrite the info already in the core Jun 04 15:08:50 yeah, don't do that ;) Jun 04 15:09:05 so when does the OCTI/OWCTI arrive? Jun 04 15:09:08 ah good point, I'll change he optin_octi_owcti_to_tech thing Jun 04 15:09:11 Is it always before a CREG? Jun 04 15:09:49 no, they appear unsolicited Jun 04 15:10:05 I tried to follow the mbm example Jun 04 15:10:16 no I mean do they appear right before CREG unsolicited? Jun 04 15:10:21 that's why I do the OCTI? before CREG Jun 04 15:12:33 so the way mbm works is that ERINFO always appears before CREG Jun 04 15:12:51 so when a cell changes, you get an ERINFO, then CREG with the new lac/ci Jun 04 15:13:25 mbm simply stores the tech reported by ERINFO and notifies the entire thing in CREG notify Jun 04 15:13:55 okay, from the logs I see the OSSYSI and OCTI/OWCTI withouth CREG afterwards Jun 04 15:14:45 feel free to post portions of the logs or pastebin them Jun 04 15:14:55 right :) Jun 04 15:16:02 do you want one with my patch applied Jun 04 15:16:18 or just a plain ofono log? Jun 04 15:16:29 with your patch applied of course ;) Jun 04 15:16:56 let me gather a new log with the patch I send you. Jun 04 15:18:45 holtmann: Any objections to breaking up the huawei driver into two drivers (or rather re-using em770 driver for the 'sane' Huaweis) Jun 04 15:25:45 denkenz: http://pastebin.com/TMKgQ5ir Jun 04 15:26:37 denkenz: I walked around in our building and from the led I saw it changing from dark blue to green and later back to dark blue Jun 04 15:29:58 so sounds like ossysi=3 is unknown Jun 04 15:30:07 yes Jun 04 15:32:02 man but the option firmware is just crap Jun 04 15:33:15 also, the side effect of you notifying the core, is lots of extra calls to COPS? Jun 04 15:33:58 so that's something we don't want Jun 04 15:34:21 No, the core queries only when CREG changes Jun 04 15:39:08 ok, so question Jun 04 15:39:30 can't you simply query octi & owcti when CREG notify is fired? Jun 04 15:39:46 and then notify the core with the whole thing? Jun 04 15:40:35 sure, I'll try that one. as I said, I really don't know what I'm doing. Jun 04 15:40:39 :) Jun 04 15:41:00 nobody does as these commands are not documented Jun 04 15:42:25 I fire the octi & owcti in the notify CREG handler? Jun 04 15:42:53 yes, but you need to delay the ofono_netreg_status_notify until you determine the tech in that case Jun 04 15:43:29 so collect the infor from CREG and then use ofono_netreg_status_notify in octi_notify Jun 04 15:43:44 yep Jun 04 15:43:51 see if that works at least Jun 04 15:44:07 okay Jun 04 15:44:24 wonder if I get that simply away withouth changing the atmodem too much :) Jun 04 15:44:57 in theory you can hide some data inside the callback structure Jun 04 15:45:21 ah, that's good to know Jun 04 15:45:31 or even storing it the main netreg_data is fine too Jun 04 15:46:24 I go for the simple approach. This can be changed later withouth problems Jun 04 15:46:44 unfortunatly I have to leave Jun 04 15:46:51 nod, lets just see if it works first Jun 04 15:47:00 no worries, have a good weekend Jun 04 15:47:03 have a nice weekend Jun 04 15:47:07 thanks Jun 04 15:47:11 cu Jun 04 19:03:09 denkenz: Makes sense to have a sane em770 and a crappy huawei drivers. Jun 04 19:05:03 akiniemi: If you are up and check this channel, please scroll back and look at my comments about ISI. Jun 04 19:06:27 denkenz: And about the Option stuff. I enabled almost every notification or command that sort of seem relevant. To see if they actually fire. Jun 04 19:07:08 yeah I know, you actually forgot one that is pretty obscure Jun 04 19:07:14 I did? Jun 04 19:07:16 it enables the OWCTI unsolicited Jun 04 19:07:47 Then lets add that one. Jun 04 19:08:27 @@ -858,6 +858,8 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, g Jun 04 19:08:27 NULL, NULL, NULL); Jun 04 19:08:27 g_at_chat_send(nd->chat, "AT_OCTI=1", none_prefix, Jun 04 19:08:27 NULL, NULL, NULL); Jun 04 19:08:28 + g_at_chat_send(nd->chat, "AT_OCTI=1", none_prefix, Jun 04 19:08:28 + NULL, NULL, NULL); Jun 04 19:08:31 g_at_chat_send(nd->chat, "AT_OSQI=1", none_prefix, Jun 04 19:08:32 NULL, NULL, NULL); Jun 04 19:08:49 yeah its supposed to be _OUWCTI Jun 04 19:08:55 Typo. Jun 04 19:10:02 _OWCTI and not _OUW.. right? Jun 04 19:10:12 no, the Option guys fucked up Jun 04 19:10:25 Anyhow, pushed. Lets see what the modem says. Jun 04 19:11:10 nope, that's wrong :) Jun 04 19:12:55 That is hilarious. Jun 04 19:13:19 Just tested it and that is really funny stuff ;) Jun 04 19:13:28 log? Jun 04 19:14:22 At least according to ModemManager, the unsolicited version is _OUWCTI Jun 04 19:14:30 However, to query, you use OWCTI? Jun 04 19:19:24 Funny funny funny. Jun 04 19:23:04 you managed to screw up that patch twice ;) Jun 04 19:23:15 anyway, now you should get reliable info Jun 04 19:24:05 I know. That is so fucked up. Jun 04 19:24:28 Btw. any reason why we are not reading the SMSC address when bringing up the SMS atom? Jun 04 19:24:40 hah, I figured out what the difference between ossysi and octi / owcti is Jun 04 19:24:55 holtmann: Why bother? It'll get read on GetProperties Jun 04 19:25:06 ofonod[6962]: App:> AT+CSCA?\r Jun 04 19:25:06 ofonod[6962]: App:< \r\n+CSCA: "+17057969300",145\r\n\r\nOK\r\n Jun 04 19:25:32 I get these in between when calling get properties. Problem could be that if GPRS and SMS has to share a channel and we have GPRS active. Jun 04 19:26:26 yeah, oFono queries things lazily Jun 04 19:26:39 keeps our start up times sane Jun 04 19:26:46 Which is great for something where you need to query the network. Jun 04 19:27:01 For this one, we might wanna make an exception and just read it ahead on startup. Jun 04 19:27:05 Forget about the shared case Jun 04 19:27:14 That will simply never work, the hardware is broken Jun 04 19:27:30 besides, the SC Address is useless Jun 04 19:27:37 we don't even use it internally Jun 04 19:27:42 Still working through my Novatel re-write to get SMS and GPRS at the same time. Jun 04 19:28:36 So tell me the difference between these Option magic commands. Jun 04 19:31:03 this is a hunch only, but Jun 04 19:31:21 ofonod[26311]: App:< \r\n_OUWCTI: 1\r\n Jun 04 19:31:23 ofonod[26311]: OWCTI mode: 1 Jun 04 19:31:24 ofonod[26311]: App:< \r\n+CGREG: 1,"FFFF","0000"\r\n\r\n_OSSYSI: 2\r\n Jun 04 19:31:26 ofonod[26311]: OSSYSI mode: 2 Jun 04 19:31:27 ofonod[26311]: App:< \r\n+CREG: 1,"FFFF","0000"\r\n Jun 04 19:31:29 Notice the ordering Jun 04 19:31:34 OWCTI is emitted prior to CGREG Jun 04 19:31:38 OSSYSI prior to CREG Jun 04 19:31:59 So OWCTI is telling the mode of the GPRS technology, while OSSYSI of the voice Jun 04 19:32:13 The cell info is bogus too, which is funny Jun 04 19:32:52 ofonod[26311]: App:> AT+CGREG?\r Jun 04 19:32:53 ofonod[26311]: App:< \r\n+CGREG: 2,1,"FFFF","0000"\r\n\r\nOK\r\n Jun 04 19:32:54 ofonod[26311]: App:< \r\n+CREG: 1,"0AEE","2737B6"\r\n\r\n+CGREG: 1,"0AEE","2737B6"\r\n Jun 04 19:33:02 The modem eventually recovers the proper lac/ci :P Jun 04 19:33:19 The firmware in these is hilarios Jun 04 19:34:55 ofonod[6962]: Control:> AT_OWANCALL=1,1,1\r Jun 04 19:34:55 ofonod[6962]: Control:< \r\nOK\r\n Jun 04 19:34:55 ofonod[6962]: App:< \r\n_OUWCTI: 4\r\n Jun 04 19:34:55 ofonod[6962]: Control:< _OWANCALL: 1, 1\r\n Jun 04 19:34:57 ofonod[6962]: Control:> AT_OWANDATA=1\r Jun 04 19:34:58 ofonod[6962]: Control:< \r\n_OWANDATA: 1, 172.28.54.84, 0.0.0.0, 64.71.255.198, 64.71.255.253, 0.0.0.0, 0.0.0.0, 72000\r\r\n\r\n\r\nOK\r\n Jun 04 19:35:00 ofonod[6962]: Got the following parameters for context: 1 Jun 04 19:35:01 ofonod[6962]: IP: 172.28.54.84, Gateway: 0.0.0.0 Jun 04 19:35:03 ofonod[6962]: DNS: 64.71.255.198, 64.71.255.253 Jun 04 19:35:05 ofonod[6962]: App:< \r\n_OUWCTI: 1\r\n Jun 04 19:36:09 tech is changing during data transfer? funny :) Jun 04 19:44:08 And what is OCTI doing now? Jun 04 19:44:23 OCTI is identical to OWCTI, just reports 2G techs Jun 04 19:44:38 Do we also have OUCTI for unsolicited updates. Jun 04 19:44:53 no, that one actually works both ways Jun 04 19:45:34 gee, why couldn't we do the same for 3G techs? That'd just make sense, can't have that Jun 04 19:57:25 ofonod[8666]: App:> AT+CPMS="ME","ME","ME"\r Jun 04 19:57:26 ofonod[8666]: App:< \r\n+CMS ERROR: 500\r\n Jun 04 19:57:26 ofonod[8666]: App:> AT+CPMS="ME","ME","ME"\r Jun 04 19:57:26 ofonod[8666]: App:< \r\n+CMS ERROR: 500\r\n Jun 04 19:57:27 ofonod[8666]: App:< \r\n_OSIGQ: 18,0\r\n Jun 04 19:57:27 ofonod[8666]: App:< \r\n+CGREG: 1,"0000","0000"\r\n Jun 04 19:57:28 ofonod[8666]: App:> AT+CPMS="ME","ME","ME"\r Jun 04 19:57:31 ofonod[8666]: App:< \r\n+CMS ERROR: 500\r\n Jun 04 19:57:39 You have seen these ones on the HSO cards. Jun 04 19:59:38 And for the cell broadcast topic. Are you planning to fallback to 0-999 or something or do we just accept that these cards are stupid. Jun 04 20:01:37 ofonod[8957]: App:> AT+CSCB=0,"4352-4356"\r Jun 04 20:01:37 ofonod[8957]: App:< \r\nOK\r\n Jun 04 20:01:43 Option seems to be fine with it. Jun 04 20:09:31 Up to the driver to do it Jun 04 20:09:40 we can quirk the novatel not to send ETWS ranges Jun 04 20:11:37 How? Jun 04 20:12:42 as a start by simply removing any range > 999 Jun 04 20:13:16 There's nothing the core can do, since the SIM can actually contain download ranges > 999 Jun 04 20:15:54 Hold on. I don't see an issue with the Novatel anymore. Jun 04 20:16:04 Was the by any chance the MBM cards when I mentioned it. Jun 04 20:16:22 I have no idea, I always thought MBM was fine with it Jun 04 20:16:55 Here it is: Jun 04 20:16:57 ofonod[9298]: GPRS:> AT+CSCB=0,"4352-4356"\r Jun 04 20:16:57 ofonod[9298]: GPRS:< \r\n+CMS ERROR: 302\r\n Jun 04 20:16:57 ofonod[9298]: Setting Cell Broadcast topics failed Jun 04 20:17:59 Does it have to do with timing? Jun 04 20:18:11 e.g. if you let the modem idle and send the same command, does it accept it? Jun 04 20:18:35 I might just have missed it. Jun 04 20:20:44 ofonod[9459]: GPRS:> AT+CSCB=1,"0-65535"\r Jun 04 20:20:44 ofonod[9459]: Modem:< \r\nOK\r\n Jun 04 20:20:44 ofonod[9459]: Modem:> AT+COPS?\r Jun 04 20:20:44 ofonod[9459]: GPRS:< \r\nOK\r\n Jun 04 20:20:58 heh Jun 04 20:21:18 CSCB=1 is different from =0 Jun 04 20:21:42 That is when we try with the modem first time. If we start ofonod again, then it fails. Jun 04 20:22:16 yeah, the CSCB=1 clears everything from the modem's accepted range Jun 04 20:22:22 ofonod[9463]: GPRS:> AT+CSCB=1,"0-65535"\r Jun 04 20:22:22 ofonod[9463]: Modem:< \r\n+CREG: 2,2\r\n\r\nOK\r\n Jun 04 20:22:22 ofonod[9463]: GPRS:< \r\nOK\r\n Jun 04 20:22:22 ofonod[9463]: GPRS:> AT+CSMS?\r Jun 04 20:22:23 then the core sends the real accepted range Jun 04 20:22:24 ofonod[9463]: Modem:> AT+CRSM=192,28488\r Jun 04 20:22:25 ofonod[9463]: Modem:< \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n Jun 04 20:22:27 ofonod[9463]: GPRS:< \r\n+CSMS: 1,1,1,1\r\n\r\nOK\r\n Jun 04 20:22:29 ofonod[9463]: GPRS:> AT+CSCB=0,"4352-4356"\r Jun 04 20:22:31 ofonod[9463]: GPRS:< \r\n+CMS ERROR: 302\r\n Jun 04 20:22:33 ofonod[9463]: Setting Cell Broadcast topics failed Jun 04 20:22:59 So what is different between a cold boot device and the second start of oFono. Jun 04 20:23:35 I have no idea Jun 04 20:23:40 ofonod[9486]: GPRS:> AT+CSCB=0,"4352-4356"\r Jun 04 20:23:40 ofonod[9486]: GPRS:< \r\nOK\r\n Jun 04 20:24:04 Only thing I can think of is that the SIM has not been initialized yet Jun 04 20:24:06 ofonod[9489]: GPRS:> AT+CSCB=0,"4352-4356"\r Jun 04 20:24:06 ofonod[9489]: GPRS:< \r\n+CMS ERROR: 302\r\n Jun 04 20:24:06 ofonod[9489]: Setting Cell Broadcast topics failed Jun 04 20:24:31 It works when the modem is fresh and clean, but every consecutive time I get an error. Jun 04 20:24:35 The SIM is ready by then. Jun 04 20:25:18 Must be just the great Novatel firmware **** ENDING LOGGING AT Sat Jun 05 02:59:57 2010