**** BEGIN LOGGING AT Wed Aug 04 02:59:57 2010 Aug 04 10:58:04 denkenz: does this make sense to you? http://pastebin.com/cZjGVVv1 I'm working on it yet, It don't work now. Aug 04 10:58:20 holtmann: ^ Aug 04 14:11:28 padovan: Do you really need a new gprs-context atom driver? Aug 04 14:34:58 kvalo: can u export OFONO_AT_DEBUG to debug ofono message? Aug 04 14:35:32 kvalo: and i would like to see dmesg output. might usb_serial will tell u some hints. Aug 04 14:35:43 zhenhua: sorry, I can't do it today Aug 04 14:36:06 i did test on my E1552 before. however, Aug 04 14:36:20 as i said, it will crash my ubuntu 10.04 Aug 04 14:36:36 kvalo: I had crashes with my Novatel card and 2.6.33 kernel of F13. Aug 04 14:36:46 And it was clearly the kernel going down. Aug 04 14:37:27 i see usb_serial model tell me some werid message and then kernel does hang Aug 04 14:39:33 well, two weeks connect/disconnect cycle was working just fine on my laptop. but the next time I'll test ofono, I'll downgrade to the exactly same kernel version I have been testing earlier. Aug 04 14:44:21 padovan: I don't think you need to copy the gprs context completely Aug 04 14:45:43 If you need to quirk, introduce a new VENDOR_DUN to vendor.h and do ofono_gprs_context_create(modem, VENDOR_DUN, "atmodem", data->chat); Aug 04 16:23:44 hi guyz, http://pastebin.com/Pt4gG4R4 -- absent of NetworkRegistration in (Modem) interfaces - is it ok? Aug 04 16:25:10 e-yes: Just use the test/list-modem script. More user friendly ;) Aug 04 16:25:20 And most likely you have to switch the ISI modem into online state. Aug 04 16:26:37 Yes, the N900 driver is slightly different from others since pessi is messing with it Aug 04 16:26:47 Try using test/enable-online Aug 04 16:28:40 unfortunatelly, i dont have python on target system (android), that's why i use dbus-send Aug 04 16:29:11 Just set the 'Online' property on Modem interface to True Aug 04 16:29:24 dbus-send doesn't support dicts ;)_ Aug 04 16:29:50 I ran into that mess with BlueZ qualification testing on Android. Not funny ;) Aug 04 16:29:53 you don't need dicts for dbus-send Aug 04 16:30:00 At least most of the time ;) Aug 04 16:30:07 Right, but you need variants. Aug 04 16:30:15 But it does support variants Aug 04 16:30:30 Anyhow, I had hard times on Android and just wrote some C based test tools for BlueZ. Aug 04 16:31:07 NetworkRegistration appears only after setting modem to online state, right? Aug 04 16:31:44 Correct, that's because Online=false means the modem's radio is off Aug 04 16:33:50 ok, thanks. it crashes (setting online prop), so i attempted to find 'easy' workaround :) will debug modem-online then Aug 04 16:42:58 e-yes: you are testing with n900? where it crashes? before returning from modem-online? Aug 04 16:44:53 pessi, http://pastebin.com/dZ0jZqTt Aug 04 16:45:30 it crashes after i run dbus-send --system --type=method_call --print-reply --dest=org.ofono --reply-timeout=120000 /isimodem org.ofono.Modem.SetProperty string:"Online" variant:boolean:true Aug 04 16:49:53 radio is on in hw (i heard specific noise). any idea what "ISI error -108" means? Aug 04 17:01:00 ;-o Aug 04 17:01:56 it seems to me that you crash the modem... Aug 04 17:02:06 line 80 Aug 04 17:04:46 sounds too pessimistic Aug 04 17:05:07 is it possible reason is gprs is 'forbidden' by operator? Aug 04 17:05:34 probably not Aug 04 17:06:58 rebooted to maemo. ussd works. at least:) Aug 04 17:07:10 e-yes: so you have pr1.2? which operator? Aug 04 17:08:25 pr1.2 in maemo, and android (run ofono under it). operator: mts rus Aug 04 17:13:32 incoming calls works too. unfortanatelly, only in maemo yet Aug 04 17:16:53 can you reproduce the debug trace with env OFONO_ISI_DEBUG=all ? Aug 04 20:17:55 balrog-k1n: Do you think we should enforce the min/max inside the agent? Aug 04 20:18:08 balrog-k1n: And e.g. forcefully remove agents that misbehave... ? Aug 04 20:27:43 so when you are doing a read of a fixed linear file, you should expect a callback for each record it reads? Aug 04 20:55:09 denkenz: I've got a question for you about reading linear files. How does the record_size get determined? Is that a predefined minimum? I notice with phonesim, although my record size is only 9 bytes, the callback always returns a record size of 20 bytes. Is that normal? Aug 04 21:15:40 kristenc: fixed linear is a record based file, so yes, a callback for each record Aug 04 21:16:19 kristenc: reading of record based files is broken into two steps Aug 04 21:17:24 first ofono sends a GET RESPONSE on the file, e.g. CRSM=192... Aug 04 21:17:43 It parses that structure, which contains the record size and total file size Aug 04 21:18:12 If the parsing is OK, it reads the records one by one using READ RECORD, e.g. CRSM=178 Aug 04 21:18:46 kristenc: for phonesim, which record are you talking about? Generally it uses the record size from the xml Aug 04 21:19:29 Are you setting the record size properly? Aug 04 21:19:33 denkenz: ah, ok, the record size must be wrong in the xml. Another thing I notice is that the data it reads isn't what I expect. Aug 04 21:19:58 Probably again because of the record size Aug 04 21:20:13 I am getting an extra byte at the beginning, but then all the other bytes are exactly what I expect. Aug 04 21:22:59 denkenz: so why is it adding this extra byte to the beginning of the record? I corrected the record size in the xml, that was not the problem. Aug 04 21:23:17 the byte is always 1 - does it mean something? Aug 04 21:24:17 Nope, it seems to work for every other record Aug 04 21:25:02 Is the file you're adding listed in simfilesystem.cpp? Aug 04 21:28:00 denkenz: I actually didn't add this file - it existed already. I'm trying to read EFimg, which was already in default.xml. However, I've made some changes to it because it wasn't formatted the way it should have been (at least by my reading of the spec). Aug 04 21:28:58 perhaps I did something wrong. I made this change: Aug 04 21:29:01 kristenc: Well the default EFimg has a 01 in the beginning for each record Aug 04 21:29:02 - Aug 04 21:29:02 - 01 2E 28 11 4F 01 00 00 00 E8 FF FF FF FF FF FF FF FF FF FF Aug 04 21:29:02 - 01 08 08 21 4F 02 00 00 00 1F FF FF FF FF FF FF FF FF FF FF Aug 04 21:29:02 - 01 18 10 11 4F 03 00 00 00 32 FF FF FF FF FF FF FF FF FF FF Aug 04 21:29:02 - 01 08 08 11 4F 04 00 00 00 0A FF FF FF FF FF FF FF FF FF FF Aug 04 21:29:03 - 01 05 05 11 4F 05 00 00 00 08 FF FF FF FF FF FF FF FF FF FF Aug 04 21:29:05 + Aug 04 21:29:07 + 05 Aug 04 21:29:09 + 2E 28 11 4F 01 00 00 00 E8 Aug 04 21:29:11 + 08 08 21 4F 02 00 00 00 1F Aug 04 21:29:13 + 18 10 11 4F 03 00 00 00 32 Aug 04 21:29:15 + 08 08 11 4F 04 00 00 00 0A Aug 04 21:29:17 + 05 05 11 4F 05 00 00 00 08 Aug 04 21:29:31 I removed the 1, because it shouldn't be there. But I still get the 1 - which I don't understand. Aug 04 21:30:04 Why do you have 05 in the beginning? Aug 04 21:30:33 denkenz: 131 102 says that byte 1 is the number of records. Aug 04 21:31:15 well, I should say "number of actual image instances" Aug 04 21:31:33 so this file (I think) is supposed to have 5 image descriptors. Aug 04 21:32:23 Somehow I think that that file should be transparent Aug 04 21:32:25 Not linear fixed Aug 04 21:32:42 131 102 says it should be linear fixed. Aug 04 21:33:29 Yeah, but image instances in a record-based file is stupid Aug 04 21:33:37 I made this change too: Aug 04 21:33:39 --- a/src/simfilesystem.cpp Aug 04 21:33:40 +++ b/src/simfilesystem.cpp Aug 04 21:33:40 @@ -110,7 +110,7 @@ static SimFileInfo const knownFiles[] = Aug 04 21:33:40 {"2F05", "3F00", "EFpl", 0x11ff44, FILE_TYPE_TRANSPARENT Aug 04 21:33:40 Aug 04 21:33:41 {"5F50", "7F10", "DFgraphics", 0, FILE_TYPE_TRANSPARENT Aug 04 21:33:43 - {"4F20", "5F50", "EFimg", 0x14ff44, FILE_TYPE_TRANSPARENT Aug 04 21:33:45 + {"4F20", "5F50", "EFimg", 0x14ff44, FILE_TYPE_LINEAR_FIXE Aug 04 21:33:47 {"4F01", "5F50", "EFimg1", 0x14ff44, FILE_TYPE_TRANSPARENT Aug 04 21:33:48 {"4F02", "5F50", "EFimg2", 0x14ff44, FILE_TYPE_TRANSPARENT Aug 04 21:33:50 {"4F03", "5F50", "EFimg3", 0x14ff44, FILE_TYPE_TRANSPARENT Aug 04 21:34:08 Unless its always one Aug 04 21:34:12 denkenz: why is it stupid? This is not the image data, just a descriptor. Aug 04 21:34:45 Yeah, so your record_size should then be 10 Aug 04 21:34:47 or 11 Aug 04 21:35:37 denkenz: I saw that, but that was confusing to me. If each descriptor is only 9 bytes, why is the record size 10 or 11? Aug 04 21:35:59 From the spec: Record length: 9n+1 or 9n+2 bytes, (n ≥ 1) Aug 04 21:36:20 The structure is given for each record Aug 04 21:36:30 So each record would have how many instances there are Aug 04 21:36:31 e.g. 1 Aug 04 21:36:59 Probably some stupid backward-compatibility BS, I need to go back to 11.11 and 51.011 Aug 04 21:37:02 I am still not understanding that. Aug 04 21:37:19 Heh, the structure is per record Aug 04 21:37:34 oh - I see - so each record has the number of instances (always 1). Aug 04 21:37:37 So each record can contain 1 .. n images Aug 04 21:37:44 yep Aug 04 21:37:48 that is pretty silly. Aug 04 21:38:45 so each record doesn't always contain only one image. Aug 04 21:39:18 Yeah, basically I think there can be multiple image instances Aug 04 21:39:20 why do you get +2 bytes if n > 1? Aug 04 21:39:22 e.g. one that is black&white Aug 04 21:39:26 one that is color Aug 04 21:39:33 so you can choose which is better suited Aug 04 21:41:56 In that respect the current EFimg in default.xml is correct Aug 04 21:42:34 Just the simfilesystem.cpp is wrong Aug 04 21:42:42 denkenz: why does the current default.xml have one image descriptor but size 20? Aug 04 21:42:51 (per record) Aug 04 21:43:00 Because the record size is constant for the entire file Aug 04 21:43:13 so you can have one instance with 2 images, and m instances with 1 image Aug 04 21:43:42 denkenz: but there is no situation like that in the EFimg in default.xml. Aug 04 21:44:05 we just have 1 descriptor, and a bunch of FF Aug 04 21:45:12 Probably the original author wanted to test the case I describe above Aug 04 21:45:33 We can modify it to have 1 or 3 images, whatever we want Aug 04 21:46:11 ok - but they just never put any extra image descriptors in there. Aug 04 21:47:56 Yeah, but that might be an oversight, etc Aug 04 21:47:57 denkenz: so why do you get a record length of 9n + 2 if n > 1? I can't see that. Aug 04 21:48:10 There's an optional RFU byte Aug 04 21:48:32 So record size can be 11 Aug 04 21:48:51 what's an RFU? Aug 04 21:49:08 Reserved for Update or something like that Aug 04 21:49:12 basically future extension byte Aug 04 21:49:22 so something to be ignored for now. Aug 04 21:49:26 yep Aug 04 21:50:06 And if n> 1, then record size cannot be 9n + 2 Aug 04 21:50:21 er, that didn't come out right Aug 04 21:50:35 the RFU byte is per entire record, not per image instance Aug 04 21:50:41 good - because that really confused me Aug 04 21:51:55 So depending on the RFU, we have record sizes: 10, 11, 19, 20, 28, 29, etc Aug 04 21:53:19 seems to me that for my purposes, the record size doesn't matter. You would just read how many image descriptors are in this record, make sure you have enough record_size to contain that and then read the data for each 9 byte descriptor out of that record. Aug 04 21:53:33 so I think I don't need to get hung up on what the record_size is. Aug 04 21:53:58 yep Aug 04 21:54:31 For multi-instance images might be good to pick the one with transparency/color/bw and larger > smaller sizes Aug 04 21:54:54 Exposing multiple images doesn't seem worth it at the moment Aug 04 21:55:36 agreed. Aug 04 21:58:50 denkenz: Do I need to quirk the modem only if it doesn't work passing 0 as parameter? Aug 04 21:59:06 I'm a bit lost on the gprs context atom. Aug 04 21:59:32 heh Aug 04 21:59:50 Tell me where you are at the moment Aug 04 21:59:59 padovan: Does dunmodem gprs-context work? Aug 04 22:04:37 denkenz: no, I only get this: Aug 04 22:04:44 ofonod[9303]: plugins/dun.c:open_device() /dev/rfcomm4 Aug 04 22:04:44 ofonod[9303]: < ~\777}#\700!}!}!} }4}"}&} } } } }%}&jW|\743}'}"}(}"\765\623~ Aug 04 22:04:44 ofonod[9303]: < ~\777}#\700!}!}!} }4}"}&} } } } }%}&jW|\743}'}"}(}"\765\623~ Aug 04 22:04:44 ofonod[9303]: < ~\777}#\700!}!}!} }4}"}&} } } } }%}&jW|\743}'}"}(}"\765\623~ Aug 04 22:04:44 ofonod[9303]: < ~\777}#\700!}!}!} }4}"}&} } } } }%}&jW|\743}'}"}(}"\765\623~ Aug 04 22:05:16 Heh, how are you setting up your DUN client? looks like its in ppp mode already Aug 04 22:05:30 I meant server, not client Aug 04 22:06:03 octal? Aug 04 22:06:03 I'm using the dund from bluez, with the -sun options Aug 04 22:06:06 how did you get that? Aug 04 22:06:34 holtmann, jhe: can you confirm that dund -sun is enough to run dun server? Aug 04 22:06:49 tmzt: Dude, OFONO_AT_DEBUG does that by default for non-printable characters Aug 04 22:07:01 --dialup -u Pretend to be a dialup/telephone Aug 04 22:07:18 denkenz: ah ok, I though it was just on a terminal Aug 04 22:07:24 didn't look closely enough Aug 04 22:07:30 too many times typing pppd Aug 04 22:07:36 and wishing I hadn't :) Aug 04 22:07:58 padovan: I'm not sure, testing against a real phone might be better Aug 04 22:08:56 denkenz: I've got another question -- when does sim_ready get called? Only once? Everytime a sim card is inserted? Aug 04 22:09:20 kristenc: Once oFono determines PIN is ready Aug 04 22:09:39 I don't have one with DUN server :( Aug 04 22:09:41 As a prerequisite, the SIM has to be inserted and PIN unlocked or PIN entered Aug 04 22:10:15 I'll look for one here, there are some N900 at ProFUSION. Aug 04 22:10:57 padovan: Do they have Garage sales in Brazil? Aug 04 22:11:15 padovan: Are you coming to Boston next week? Aug 04 22:11:28 I don't think so if they have. Aug 04 22:11:38 denkenz: yes, I'm going. Aug 04 22:11:51 padovan: Ok, I rummage for some old phones and give you some to try Aug 04 22:12:35 denkenz: Nice. That will help. ;) **** ENDING LOGGING AT Thu Aug 05 02:59:56 2010