**** BEGIN LOGGING AT Thu Jun 03 02:59:57 2010 Jun 03 03:01:30 holtmann: Go for it, I'm surprised you haven't already Jun 03 03:03:55 Btw. all test scripts should be in EXTRA_DIST. Just a reminder since the online bits had been forgotten. Jun 03 03:06:01 nod Jun 03 03:09:02 ofono-0.22.tar.gz is uploading. Jun 03 03:10:48 we should really do mailing list announcements at some point Jun 03 03:11:19 I won't even mention the barren wasteland of ofono.org ;) Jun 03 03:52:46 denkenz: Do we have to register atoms only in pre_sim and post_sim? Jun 03 03:52:54 Or can we register them at any time later? Jun 03 03:53:02 we can register them any time Jun 03 03:53:38 just to be sure, you're asking about _register or _create? Jun 03 03:53:42 For the Novatel cards, I have to first switch the second TTY from QCDM to AT command more, before I can use it for GPRS. Jun 03 03:54:06 So I only wanna register the GPRS atoms once I have that port available. Jun 03 03:54:35 yeah _register can be done any time Jun 03 03:54:45 _create can be done any time as well, but it is trickier Jun 03 03:58:21 I am asking about _create. Jun 03 03:58:23 ofonod[4846]: > AT+CIND=?\r Jun 03 03:58:23 ofonod[4846]: < AT+CIND=?\r\r\nERROR\r\n Jun 03 03:58:23 ofonod[4846]: This driver is not setup with Signal Strength reporting via CIND indications, please write proper netreg handling for this device Jun 03 04:01:23 The no CIND support seems to be Qualcomm related thing. Jun 03 04:01:50 you need to quirk the novatel with its vendor signal strength event Jun 03 04:02:02 cind works on most ericsson modems Jun 03 04:04:22 about the _create, for the previous design it was actually fine Jun 03 04:04:57 However, now that we have online state we might have to introduce another parameter specifying which stage this atom belongs in Jun 03 04:05:12 or maybe a _set method Jun 03 04:05:42 The calypso needs it, since it notifies us of phonebook / sms availability well past post_sim Jun 03 04:06:26 sounds like you need it as well Jun 03 04:07:09 for now if the driver doesn't implement post_online method it doesn't matter, but this needs some attention Jun 03 04:14:24 holtmann: Btw, can't you switch from qcdm as part of the power up process? Jun 03 04:14:43 Looking into that one. Jun 03 04:15:00 I might just put it before AT+CFUN=1 Jun 03 04:15:23 that's what I would do, if that port fails to be de-qcdm-ed then we should as well give up Jun 03 05:01:52 So I have this working now. Jun 03 05:02:15 Only problem is that CGATT might fail if modem power is too quick. Seems like a race condition. Jun 03 05:02:50 ofonod[6578]: Modem:< \r\nNO CARRIER\r\n Jun 03 05:02:50 ofonod[6578]: GPRS:< \r\nNO CARRIER\r\n Jun 03 05:02:55 Comes in on both ports. Jun 03 05:04:03 Other than that, context activation, deactivation works just fine. Jun 03 05:06:16 ofonod[6735]: GPRS:> AT+CGAUTO=0\r Jun 03 05:06:17 ofonod[6735]: GPRS:< \r\nERROR\r\n Jun 03 05:06:41 [ org.ofono.DataConnectionManager ] Jun 03 05:06:41 Powered = 1 Jun 03 05:06:41 Attached = 0 Jun 03 05:06:53 org.ofono.Error.NotAttached: GPRS is not attached Jun 03 05:06:58 When I am trying to activate. Jun 03 05:07:54 ofonod[6741]: GPRS:> AT+CGATT=1\r Jun 03 05:07:54 ofonod[6741]: Modem:< \r\nOK\r\n Jun 03 05:07:54 ofonod[6741]: Modem:> AT+COPS?\r Jun 03 05:07:54 ofonod[6741]: GPRS:< \r\n+CREG: 2,,\r\n\r\n+CGREG: 2,,\r\n\r\n+CME ERROR: no network service\r\n Jun 03 05:08:09 denkenz: So we get an error on CGATT. Jun 03 05:08:36 we don't get an error on cgatt Jun 03 05:08:45 we get some weird unsolicited error Jun 03 05:09:36 ofonod[6741]: GPRS:> AT+CGREG?\r Jun 03 05:09:36 ofonod[6741]: Modem:< \r\n+COPS: 0\r\n\r\nOK\r\n Jun 03 05:09:36 ofonod[6741]: Modem:> AT+COPS=3,0\r Jun 03 05:09:36 ofonod[6741]: GPRS:< \r\n+CGREG: 2,2\r\n\r\nOK\r\n Jun 03 05:09:36 ofonod[6741]: Modem:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:09:39 ofonod[6741]: GPRS:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:09:46 I think that modem is just stupid. Jun 03 05:10:13 also, I don't get this part: [00:02] Only problem is that CGATT might fail if modem power is too quick. Seems like a race condition. Jun 03 05:10:36 ofonod[6748]: GPRS:> AT+CGATT=1\r Jun 03 05:10:36 ofonod[6748]: Modem:< \r\nOK\r\n Jun 03 05:10:36 ofonod[6748]: Modem:> AT+COPS?\r Jun 03 05:10:36 ofonod[6748]: GPRS:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n\r\nOK\r\n Jun 03 05:10:36 ofonod[6748]: GPRS:> AT+CGREG?\r Jun 03 05:10:37 ofonod[6748]: Modem:< \r\n+COPS: 0,2,"302720",2\r\n\r\nOK\r\n Jun 03 05:10:39 ofonod[6748]: Modem:> AT+COPS=3,0\r Jun 03 05:10:40 ofonod[6748]: GPRS:< \r\n+CGREG: 2,1,FE38,EBD6\r\n\r\nOK\r\n Jun 03 05:10:49 And that is when it succeeds. Jun 03 05:11:07 seems reasonable Jun 03 05:11:19 ofono is actually doing the right thing Jun 03 05:12:34 So how do we get this working properly. Jun 03 05:13:05 Btw. I am still using the v1 parser with the Novatel modem. Jun 03 05:13:43 Or should I just disable the extended error crap. Jun 03 05:14:05 hmm Jun 03 05:14:34 Send a CMEE=1 on both ports to disable the verbose reporting Jun 03 05:14:37 Also we never asked for the CREG notifications on the GPRS channel, but it sends it anyway ;) Jun 03 05:14:50 CMEE=1 ?> Jun 03 05:14:54 Not CMEE=0 Jun 03 05:15:13 yeah, CMEE=1 Jun 03 05:16:32 so I don't get it Jun 03 05:16:44 how is it that your modem is sending CGATT=1 when its not even registered Jun 03 05:17:15 No idea. Jun 03 05:17:27 ofonod[6891]: Modem:> AT+COPS?\r Jun 03 05:17:28 ofonod[6891]: GPRS:< \r\n+CREG: 2,,\r\n\r\n+CGREG: 2,,\r\n\r\n+CME ERROR: 30\r\n Jun 03 05:17:34 That is with CMEE=1 ;) Jun 03 05:17:37 the core doesn't send a set_attached until CREG is registered Jun 03 05:18:10 ofonod[6891]: Modem:> AT+CREG?\r Jun 03 05:18:10 ofonod[6891]: GPRS:> AT+CGREG=?\r Jun 03 05:18:10 ofonod[6891]: Modem:< \r\n+CREG: 2,2\r\n\r\nOK\r\n Jun 03 05:18:10 ofonod[6891]: GPRS:< \r\n+CGREG: (0-2)\r\n\r\nOK\r\n Jun 03 05:18:10 ofonod[6891]: GPRS:> AT+CGREG=2\r Jun 03 05:18:12 ofonod[6891]: GPRS:< \r\nOK\r\n Jun 03 05:18:13 ofonod[6891]: GPRS:> AT+CGAUTO=0\r Jun 03 05:18:15 ofonod[6891]: GPRS:< \r\nERROR\r\n Jun 03 05:18:19 ofonod[6891]: GPRS:> AT+CGEREP=2,1\r Jun 03 05:18:20 ofonod[6891]: GPRS:< \r\nOK\r\n Jun 03 05:18:22 ofonod[6891]: Modem:< \r\n+CREG: 1,FE38,DEB7\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:18:24 ofonod[6891]: GPRS:< \r\n+CREG: 1,FE38,DEB7\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:19:11 okay, so you have main net registration and no gprs Jun 03 05:19:29 sending cgatt=1 at this point gives you an error? Jun 03 05:19:41 Some times. Not always. Jun 03 05:20:25 ofonod[6904]: Modem:> AT+CREG=?\r Jun 03 05:20:25 ofonod[6904]: GPRS:> ATE0 +CMEE=1\r Jun 03 05:20:25 ofonod[6904]: Modem:< \r\n+CREG: (0-2)\r\n\r\nOK\r\n Jun 03 05:20:25 ofonod[6904]: GPRS:< \r\nOK\r\n Jun 03 05:20:27 ofonod[6904]: Modem:> AT+CRSM=192,28480\r Jun 03 05:20:27 ofonod[6904]: GPRS:> AT+CGDCONT=?\r Jun 03 05:20:29 ofonod[6904]: Modem:< \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n Jun 03 05:20:30 ofonod[6904]: GPRS:< \r\n+CGDCONT: (1-16),"IP",,,(0-2),(0-2)\r\n+CGDCONT: (1-16),"PPP",,,(0-2),(0-2)\r\n\r\nOK\r\n Jun 03 05:20:33 ofonod[6904]: Modem:> AT+CREG=2\r Jun 03 05:20:35 ofonod[6904]: GPRS:> AT+CGREG=?\r Jun 03 05:20:37 ofonod[6904]: Modem:< \r\nOK\r\n Jun 03 05:20:39 ofonod[6904]: GPRS:< \r\n+CGREG: (0-2)\r\n\r\nOK\r\n Jun 03 05:20:41 ofonod[6904]: Modem:> AT+CREG?\r Jun 03 05:20:43 ofonod[6904]: GPRS:> AT+CGREG=2\r Jun 03 05:20:45 ofonod[6904]: Modem:< \r\n+CREG: 2,2\r\n\r\nOK\r\n Jun 03 05:20:49 ofonod[6904]: GPRS:< \r\nOK\r\n Jun 03 05:20:51 ofonod[6904]: GPRS:> AT+CGAUTO=0\r Jun 03 05:20:53 ofonod[6904]: GPRS:< \r\nERROR\r\n Jun 03 05:20:55 ofonod[6904]: GPRS:> AT+CGEREP=2,1\r Jun 03 05:20:57 ofonod[6904]: GPRS:< \r\nOK\r\n Jun 03 05:20:59 ofonod[6904]: Modem:< \r\n+CREG: 1,FE38,BA76\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:21:01 ofonod[6904]: GPRS:< \r\n+CREG: 1,FE38,BA76\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:21:03 ofonod[6904]: Modem:> AT+COPS=3,2\r Jun 03 05:21:05 ofonod[6904]: GPRS:> AT+CGATT=1\r Jun 03 05:21:07 ofonod[6904]: Modem:< \r\nOK\r\n Jun 03 05:21:09 ofonod[6904]: Modem:> AT+COPS?\r Jun 03 05:21:11 ofonod[6904]: GPRS:< \r\n+CREG: 1,FE38,BA76\r\n\r\n+CGREG: 1,FE38,BA76\r\n\r\nOK\r\n Jun 03 05:21:13 ofonod[6904]: GPRS:> AT+CGREG?\r Jun 03 05:21:15 ofonod[6904]: Modem:< \r\n+COPS: 0,2,"302720",2\r\n\r\nOK\r\n Jun 03 05:21:19 ofonod[6904]: Modem:> AT+COPS=3,0\r Jun 03 05:21:21 ofonod[6904]: GPRS:< \r\n+CGREG: 2,1,FE38,BA76\r\n\r\nOK\r\n Jun 03 05:21:23 ofonod[6904]: Modem:< \r\nOK\r\n Jun 03 05:21:25 ofonod[6904]: Modem:> AT+COPS?\r Jun 03 05:21:27 ofonod[6904]: Modem:< \r\n+COPS: 0,0,"ROGERS",2\r\n\r\nOK\r\n Jun 03 05:21:29 This is the success case. Jun 03 05:21:49 The difference is just how quick I enable the modem. If I wait a bit we are fine, if I am too quick it fails. Jun 03 05:21:53 This is the failure case. Jun 03 05:21:55 ofonod[6910]: GPRS:> AT+CGDCONT=?\r Jun 03 05:21:55 ofonod[6910]: Modem:< \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n Jun 03 05:21:55 ofonod[6910]: GPRS:< \r\n+CGDCONT: (1-16),"IP",,,(0-2),(0-2)\r\n+CGDCONT: (1-16),"PPP",,,(0-2),(0-2)\r\n\r\nOK\r\n Jun 03 05:21:56 ofonod[6910]: Modem:> AT+CREG=2\r Jun 03 05:21:57 ofonod[6910]: GPRS:> AT+CGREG=?\r Jun 03 05:21:58 ofonod[6910]: Modem:< \r\nOK\r\n Jun 03 05:21:59 ofonod[6910]: Modem:> AT+CREG?\r Jun 03 05:22:01 ofonod[6910]: GPRS:< \r\n+CGREG: (0-2)\r\n\r\nOK\r\n Jun 03 05:22:03 ofonod[6910]: GPRS:> AT+CGREG=2\r Jun 03 05:22:05 ofonod[6910]: Modem:< \r\n+CREG: 2,2\r\n\r\nOK\r\n Jun 03 05:22:07 ofonod[6910]: GPRS:< \r\nOK\r\n Jun 03 05:22:09 ofonod[6910]: GPRS:> AT+CGAUTO=0\r Jun 03 05:22:11 ofonod[6910]: GPRS:< \r\nERROR\r\n Jun 03 05:22:13 ofonod[6910]: GPRS:> AT+CGEREP=2,1\r Jun 03 05:22:15 ofonod[6910]: GPRS:< \r\nOK\r\n Jun 03 05:22:19 ofonod[6910]: Modem:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:22:21 ofonod[6910]: GPRS:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 0,,\r\n Jun 03 05:22:22 ofonod[6910]: Modem:> AT+COPS=3,2\r Jun 03 05:22:24 ofonod[6910]: GPRS:> AT+CGATT=1\r Jun 03 05:22:27 ofonod[6910]: Modem:< \r\nOK\r\n Jun 03 05:22:28 ofonod[6910]: Modem:> AT+COPS?\r Jun 03 05:22:31 ofonod[6910]: GPRS:< \r\n+CREG: 2,,\r\n\r\n+CGREG: 2,,\r\n\r\n+CME ERROR: 30\r\n Jun 03 05:22:33 ofonod[6910]: GPRS:> AT+CGREG?\r Jun 03 05:22:34 ofonod[6910]: Modem:< \r\n+COPS: 0\r\n\r\nOK\r\n Jun 03 05:22:37 ofonod[6910]: Modem:> AT+COPS=3,0\r Jun 03 05:22:39 ofonod[6910]: GPRS:< \r\n+CGREG: 2,2\r\n\r\nOK\r\n Jun 03 05:22:40 ofonod[6910]: Modem:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:22:43 ofonod[6910]: GPRS:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:22:44 ofonod[6910]: Modem:< \r\nOK\r\n Jun 03 05:22:49 ofonod[6910]: Modem:> AT+COPS?\r Jun 03 05:22:50 ofonod[6910]: Modem:< \r\n+COPS: 0,0,"ROGERS",2\r\n\r\nOK\r\n Jun 03 05:22:53 ofonod[6910]: Modem:> AT+COPS=3,2\r Jun 03 05:22:55 ofonod[6910]: Modem:< \r\nOK\r\n Jun 03 05:22:57 ofonod[6910]: Modem:> AT+COPS?\r Jun 03 05:22:58 ofonod[6910]: Modem:< \r\n+COPS: 0,2,"302720",2\r\n\r\nOK\r\n Jun 03 05:23:01 ofonod[6910]: Modem:> AT+COPS=3,0\r Jun 03 05:23:03 ofonod[6910]: Modem:< \r\nOK\r\n Jun 03 05:23:05 ofonod[6910]: Modem:> AT+COPS?\r Jun 03 05:23:07 ofonod[6910]: Modem:< \r\n+COPS: 0,0,"ROGERS",2\r\n\r\nOK\r\n Jun 03 05:23:08 I have everything on Modem TTY, but GPRS related settings on the second TTY. Jun 03 05:23:11 We only use devinfo, sim, netreg and gprs, gprs-ctx atoms. Jun 03 05:23:41 okay, so the failure occurs because the modem does a cell reselection right after reporting successful netreg Jun 03 05:26:09 try: Jun 03 05:26:10 --- a/src/gprs.c Jun 03 05:26:12 +++ b/src/gprs.c Jun 03 05:26:13 @@ -1321,10 +1321,6 @@ void ofono_gprs_detached_notify(struct ofono_gprs *gprs) Jun 03 05:26:15 Jun 03 05:26:16 void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status) Jun 03 05:26:18 { Jun 03 05:26:19 - /* If we are not attached and haven't tried to attach, ignore */ Jun 03 05:26:21 - if (gprs->driver_attached == FALSE) Jun 03 05:26:22 - return; Jun 03 05:26:24 - Jun 03 05:26:25 gprs->status = status; Jun 03 05:26:27 gprs_attached_update(gprs); Jun 03 05:26:28 } Jun 03 05:27:18 this is the weird auto-attach behavior, we need some way for the core to handle it Jun 03 05:27:19 Also CMEE=0 makes it work better, but might also crash the second port. Jun 03 05:27:43 CMEE=0 should just result in ERROR being printed instead of +CME ERROR: 30 Jun 03 05:28:04 Unless the firmware is totally broken I don't see how it could affect anything :P Jun 03 05:28:29 ofonod[7129]: Modem:> AT+COPS?\r Jun 03 05:28:30 ofonod[7129]: GPRS:< \r\n+CREG: 2,,\r\n\r\n+CGREG: 2,,\r\n\r\n+CME ERROR: 30\r\n Jun 03 05:28:34 Doesn't help. Jun 03 05:28:43 It won't help with that part Jun 03 05:28:56 However, subsequent CGREG should switch Attached to 1 Jun 03 05:29:01 CMEE=0 results in OK or CGATT to not return at all. Jun 03 05:29:36 Nope that CGREG doesn't do anything. Attached=0. Jun 03 05:31:09 ok yeah that only solves part of the issue Jun 03 05:38:28 aha Jun 03 05:38:46 I see why its not working, the CREG notification only arrives on the GPRS port Jun 03 05:39:26 No. It arrives on both ports. Jun 03 05:39:51 ofonod[7140]: Modem:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:39:51 ofonod[7140]: GPRS:< \r\n+CREG: 1,FE38,EBD6\r\n\r\n+CGREG: 1,FE38,EBD6\r\n Jun 03 05:39:55 GPRS:< \r\n+CREG: 2,,\r\n\r\n+CGREG: 2,,\r\n\r\n+CME ERROR: 30\r\n Jun 03 05:40:15 The CREG: 2 in between two successful CREGs is only the GPRS port Jun 03 05:40:31 hence the core still thinks it is happily registered Jun 03 05:41:42 Meaning I need to parse the CREG on the GPRS port and feed it into netreg atom. Jun 03 05:42:01 yep, potentially Jun 03 05:42:06 that modem is just stupid Jun 03 05:42:54 You can also try forcing driver_attached = TRUE in ofono_gprs_status_notify if status == 2 or 5 Jun 03 05:43:20 I think we need a hint to oFono that modem auto-attaches Jun 03 05:44:41 So if I take the CGATT out of the GPRS atom, then this should be fine. Jun 03 05:45:03 it would be fine the first time Jun 03 05:45:26 once we set Powered=False on gprs atom it would need to send the CGATT Jun 03 05:45:43 so subsequent Powered=True would also need to trigger the CGATT Jun 03 05:46:36 [holtmann@aeonflux test]$ ../gatchat/gsmdial Jun 03 05:46:36 IP: (null) Jun 03 05:46:36 Port: 0 Jun 03 05:46:36 Segmentation fault (core dumped) Jun 03 05:46:39 Sweet ;) Jun 03 05:46:52 yeah that's been there a while Jun 03 05:47:33 probably since I wrote it ;) Jun 03 05:47:55 : > AT+CPIN?\r Jun 03 05:47:55 : < \r\n+CPIN: READY\r\n\r\nOK\r\n Jun 03 05:47:55 : > AT+CREG=2\r Jun 03 05:47:55 : < \r\nOK\r\n Jun 03 05:47:56 : > AT+CGREG=2\r Jun 03 05:47:56 : < \r\nOK\r\n Jun 03 05:47:59 : > AT+COPS=0\r Jun 03 05:47:59 : < \r\nERROR\r\n Jun 03 05:48:01 From gsmdial ;) Jun 03 05:48:20 : > AT+CPIN?\r Jun 03 05:48:21 : < \r\n+CPIN: READY\r\n\r\nOK\r\n Jun 03 05:48:21 : > AT+CREG=2\r Jun 03 05:48:21 : < \r\nOK\r\n Jun 03 05:48:23 : > AT+CGREG=2\r Jun 03 05:48:23 : < \r\nOK\r\n Jun 03 05:48:25 : > AT+COPS=0\r Jun 03 05:48:25 : < \r\nOK\r\n Jun 03 05:48:28 Waiting for network registration... Jun 03 05:48:29 : > AT+CREG?\r Jun 03 05:48:31 : < \r\n+CREG: 2,1,FE38,EBD6\r\n\r\nOK\r\n Jun 03 05:48:33 Registered to network, roaming=false Jun 03 05:48:35 Activating GPRS network... Jun 03 05:48:37 : > AT+CGATT=1\r Jun 03 05:48:39 : < \r\nOK\r\n Jun 03 05:48:41 : > AT+CGREG?\r Jun 03 05:48:43 : < \r\n+CGREG: 2,1,FE38,EBD6\r\n\r\nOK\r\n Jun 03 05:48:45 Registered to GPRS network, roaming=false Jun 03 05:48:49 : > AT+CGDCONT=1,"IP","internet.com"\r Jun 03 05:48:51 : < \r\nOK\r\n Jun 03 05:48:53 : > AT+CGDATA="PPP",1\r Jun 03 05:48:55 : < \r\nCONNECT HSDPA 7.2\r\n Jun 03 05:48:57 Second time it works just fine. Jun 03 05:48:59 Could be that the CGCONT triggers the auto-attach? Jun 03 05:49:01 We are doing that before calling CGATT actually. Jun 03 05:49:21 no, CGDCONT is only relevant for CGDATA Jun 03 05:49:36 the attach is triggered automatically by CFUN=1 or COPS=0 Jun 03 05:49:45 According to the spec., but not with this modem. Maybe they trigger it via that one. Jun 03 05:49:59 via CGDCONT? doubtful Jun 03 05:50:23 it auto-attaches gprs just like every other usb stick in existence Jun 03 05:50:40 just that mbm and hso actually report CREG: 2 properly Jun 03 05:51:58 most vendors actually have a command to turn that auto-attach behavior off Jun 03 05:52:30 So I need to feed the CREG from GPRS channel into netreg. That seems to be the only way. Jun 03 05:53:52 its not the 'only' way Jun 03 05:55:05 I am open for ideas. Jun 03 05:57:30 index dfb6d16..aff5bed 100644 Jun 03 05:57:32 --- a/src/gprs.c Jun 03 05:57:33 +++ b/src/gprs.c Jun 03 05:57:35 @@ -1321,9 +1321,10 @@ void ofono_gprs_detached_notify(struct ofono_gprs *gprs) Jun 03 05:57:36 Jun 03 05:57:38 void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status) Jun 03 05:57:39 { Jun 03 05:57:41 - /* If we are not attached and haven't tried to attach, ignore */ Jun 03 05:57:42 - if (gprs->driver_attached == FALSE) Jun 03 05:57:44 - return; Jun 03 05:57:45 + if (gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED || Jun 03 05:57:47 + gprs->status == NETWORK_REGISTRATION_STATUS_ROAMING && Jun 03 05:57:48 + gprs->driver_attached == FALSE) Jun 03 05:57:50 + gprs->driver_attached = TRUE; Jun 03 05:57:51 Jun 03 05:57:53 gprs->status = status; Jun 03 05:57:54 gprs_attached_update(gprs); Jun 03 05:57:56 that would in theory force it into attached state Jun 03 06:00:21 we need to take care of this in case we auto-attach and roaming Jun 03 06:03:04 let me fiddle with it tomorrow Jun 03 06:03:16 Lets see if I can get my German sims to roam to test this out :) Jun 03 06:07:37 I have this working fine now with parsing the CREG on the GPRS channel and updating netreg atom. Jun 03 06:09:50 It goes from registers -> searching -> registered. Jun 03 06:11:36 Do you have a Novatel modem? Jun 03 06:16:23 denkenz: Do you want me to commit what I have so far? Jun 03 06:23:46 denkenz: SMS is fucked up on this modem. Jun 03 06:43:28 ofonod[8921]: Modem:> AT+CMGL=4\r Jun 03 06:43:28 ofonod[8921]: Modem:< \r\n+CMGL: 65536,0,,24\r\n07917150979603F0040B917187990757F000000160203272712905207A794E07\r\nOK\r\n Jun 03 06:43:28 ofonod[8921]: Incoming SMS on modem: 0x1399690 Jun 03 06:43:28 ofonod[8921]: InternalMessageId: 8 Jun 03 06:43:30 ofonod[8921]: From: +17789970750 Jun 03 06:43:30 ofonod[8921]: Local Sent Time: 2010-06-02T19:27:17-0700 Jun 03 06:43:32 ofonod[8921]: Remote Sent Time: 2010-06-02T23:27:17-0300 Jun 03 06:43:34 ofonod[8921]: Text: test Jun 03 06:43:36 ofonod[8921]: Modem:> AT+CMGD=65536\r Jun 03 06:43:38 ofonod[8921]: Modem:< \r\n+CMS ERROR: 321\r\n Jun 03 06:43:40 ofonod[8921]: Unable to delete received SMS Jun 03 06:43:42 I am having fun with this modem. Jun 03 13:16:39 holtmann: Sure commit Jun 03 18:29:30 kvalo: I pushed the patches to make the Novatel data dongles work. Jun 03 18:39:33 holtmann: cool! Jun 03 18:45:07 kvalo: Next one is your turn. Jun 03 18:54:33 So I'm playing with my Huawei E160G Jun 03 18:54:47 It has two ttys, usbn and usbn + 1 Jun 03 18:55:26 Seems USBn with interface=00 is flagged as modem port Jun 03 18:55:38 and USBn + 1 with interface=01 is flagged as PCUI port Jun 03 18:56:04 However, I've not found any way to query the at tty itself to figure out which port it thinks it is Jun 03 18:58:10 holtmann: heh. I haven't done my ebay shopping yet :) Jun 03 18:58:34 denkenz: now that's depressing :( Jun 03 18:59:07 NetworkManager solves this by listening to ^BOOT: messages on both ports Jun 03 18:59:35 if such a message arrives in x seconds it flags it as the unsolicited or PCUI port Jun 03 19:51:32 what's wrong with relying on the bInterface? Jun 03 20:09:19 balrog-k1n: Because other Huawei devices come with 3 ttys Jun 03 20:09:32 1 modem, 1 qcdm, 1 unsolicited Jun 03 20:22:25 Funny that Mac OS X actually identifies the Pcui / Modem ports correctly Jun 03 20:41:46 So the Novatel is not giving us cell updates. Jun 03 20:41:52 So CREG is utterly broken. Jun 03 20:42:16 it gave updates in your previous logs Jun 03 20:43:10 Just, but only for that brief time of CGATT. Other than that. Nothing. Jun 03 20:43:29 I am sitting in a train and must have passed 15 different base stations so far. No updates. Jun 03 20:43:42 heh Jun 03 20:44:06 kvalo: Once we fix this routing issue with ppp0 in ConnMan, this works so nicely. Jun 03 20:45:15 And I am actually underground ;) Jun 03 20:45:43 show off Jun 03 20:48:31 Is lsusb -v the fullest level of info, or is there something that can poke into the usb descriptors to give more information? Jun 03 21:05:31 the files in /sys/class/usb_device/usbdev1.1/device/ Jun 03 21:05:53 but lsusb should have most of the same info Jun 03 21:06:14 if not all Jun 03 21:06:43 then the usb descriptor doesn't really have any hints as to what is Modem or PCUI ports Jun 03 21:07:59 The order of the USB interfaces is normally fixed. Jun 03 21:09:06 yeah, the combination of product id + configuration number + interface number should be reliable Jun 03 21:09:59 In that case I'm again leaning towards just hardcoding this into ofono.rules Jun 03 21:10:07 There is no auto-detection that we can do here Jun 04 02:18:45 ofonod[29473]: App:< \r\n+COPS: (2,"WIND Home","WIND Home","302490",2),(1,"WIND Away","WIND Away","302610",2),(1,"WIND Away","WIND Away","302720",2),(1,"WIND Away","WIND Away","302720",0),(1,"WIND Away","WIND Away","302220",2),,(0,1,2,3,4),(0,1,2)\r\n\r\nOK\r\n Jun 04 02:19:14 Some fun with our new operator here. The SIM overwrites all other operator names with "Away" since they are roaming partners ;) Jun 04 02:21:44 Quad band UMTS modems are fun. Jun 04 02:34:44 akiniemi: Any reason the GPRS support is not showing up when using the N900 via USB cable? Jun 04 02:37:32 {NetworkRegistration} [/isimodem1/operator/302490] Technologies = gsm umts Jun 04 02:37:32 {NetworkRegistration} [/isimodem1] Name = WIND Jun 04 02:37:32 {NetworkOperator} [/isimodem1/operator/302490] Name = WIND Jun 04 02:37:44 [ /isimodem1 ] Jun 04 02:37:44 [ /isimodem1/operator/302490 ] Jun 04 02:37:44 Status = current Jun 04 02:37:44 Technologies = gsm umts Jun 04 02:37:46 MobileNetworkCode = 490 Jun 04 02:37:46 Name = WIND Jun 04 02:37:49 MobileCountryCode = 302 Jun 04 02:38:10 akiniemi: Also something is wrong here. Wind is 3G only and this is HSPA / 3.5G mode. And not GSM + UMTS. **** ENDING LOGGING AT Fri Jun 04 02:59:57 2010