**** BEGIN LOGGING AT Wed Dec 29 02:59:57 2010 Dec 29 11:10:06 balrog-k2n, denkenz: ping Dec 29 14:26:55 Jeevaka: pong Dec 29 15:12:09 hi. i discovered a problem with "powered" and "online". i get the error org.ofono.Error.NotImplemented: Implementation not provided when trying to set online to true. is that a bug? Dec 29 15:40:45 The driver doesn't implement that method Dec 29 15:41:04 so it could be a bug, or intentional Dec 29 15:41:09 depends on the driver Dec 29 16:08:41 denkenz: that means the driver comes online without request? how can i implement a reliable client if the daemon behaves that different? Dec 29 16:09:01 denkenz: it's the calypso btw... Dec 29 16:09:26 denkenz: also that cores in the muxer part quite often... :/ Dec 29 16:14:56 The calypso driver needs a bit more love :( Dec 29 16:19:33 calypso is a special beast *cough* Dec 29 16:20:08 Actually oFono core relies on the driver to do the right thing Dec 29 16:20:15 some drivers *explicitly* do not support onlining Dec 29 16:20:23 and the core does the right thing in that case Dec 29 16:20:33 if the driver doesn't implement it, then its a bug in the driver Dec 29 16:20:44 And yes, the calypso driver has been bit-rotting for a while Dec 29 16:43:15 emdete: is Online False when you're trying to set it? Dec 29 16:44:13 if it's True, just leave it alone, although perhaps the driver shouldn't return not-implemented when you're trying to set Dec 29 16:45:05 only when trying to unset Online Dec 29 16:45:22 balrog-k2n: will check that Dec 29 16:46:08 if the driver doesn't implement set_online oFono automatically assumes the modem goes online Dec 29 16:46:36 This is useful for BT HFP which has no concept of Flight mode Dec 29 16:50:28 balrog-k2n: Online is false in that moment. how can i determine if that call is supporting /before/ catching that error? Dec 29 16:53:31 hmm it shouldn't be false i guess Dec 29 16:53:47 unless powered is false as well Dec 29 16:54:54 so calypso does not work, huawei doesn't either and our n900 setup doesn't show any modems at all :/ Dec 29 16:58:19 emdete: For the N900 make sure you have the latest ofono.rules files and a proper udev version. There where some issues. Dec 29 16:59:03 I'm not sure what's happening with the calypso, but your onlining troubles are not because of set_online being not implemented Dec 29 16:59:22 the main trouble is core dumping, exiting, ... Dec 29 16:59:50 feel free to post gdb traces Dec 29 17:00:06 there seems to be some issue with muxing, it crashed after receiving a call Dec 29 17:00:11 holtmann: which udev version is not proper? Dec 29 17:00:40 I don't know. I heard about some scratchbox issues. Dec 29 17:00:50 And either Ubuntu or Debian. Dec 29 17:00:54 I never had a problem. Dec 29 17:00:55 also it says something that the system dbus connection dropped and exists Dec 29 17:00:57 The Neophysis guys have been using oFono with the Freerunner for ages, and we haven't heard of any muxer crashes Dec 29 17:00:59 the set_online problem could be a result of the lockdown changes (not checked, just thinking aloud) Dec 29 17:01:21 doubtful, but can be Dec 29 17:01:24 denkenz: muxer was the last debug logging line before the sig 11 Dec 29 17:01:34 that means nothing Dec 29 17:01:38 sure Dec 29 17:02:11 run ofono on your desktop with the phonesim driver and the calypso hacks Dec 29 17:02:20 and export the modem over tcp Dec 29 17:02:29 that way you can debug more easily Dec 29 17:03:32 emdete: make sure ofono isn't asking for a PIN when you're setting Online Dec 29 17:04:23 exporting over tcp works great in general, the only annoying issue is that the calypso (with the firmware as found in FR) is not able to drop out of mux mode... so you need a restart every time Dec 29 17:04:51 yes, you need a script to reboot the modem Dec 29 17:04:58 *nod* Dec 29 17:05:01 but for debugging it beans gdbserver Dec 29 17:05:07 heh, for sure Dec 29 17:05:08 beats that is Dec 29 17:06:10 that's why i'm struggling w/ n900 forwarding atm. Dec 29 17:06:18 just can't get it to work when not running maemo Dec 29 17:06:25 looking for the missing link (sic!) Dec 29 17:06:56 maybe the checks "if (driver->set_online == NULL)" and "if (modem->online == online)" in set_property_online, should have their order changed? Dec 29 17:07:17 won't matter in this case Dec 29 17:07:23 the modem is offline because it has a sim atom Dec 29 17:07:28 and the sim has not signaled ready Dec 29 17:07:46 but in general it would seem more logical Dec 29 17:08:39 maybe, though you shouldn't be setting online on such a modem anyway Dec 29 17:09:18 as you'll get the same issue when trying to go offline ;) Dec 29 17:09:49 denkenz: why isn't there a way if the modem has this capability? Dec 29 17:10:12 nobody asked for it yet Dec 29 17:10:38 i thouhgt it's abvious ;) Dec 29 17:10:55 not necessarily Dec 29 17:10:59 most UIs are platform specific Dec 29 17:11:40 You either design for the HFP usecase or for the real modem usecase Dec 29 17:11:54 Nobody has attempted to make a generic desktop UI for oFono -> no feature Dec 29 17:14:26 And its actually trivial to add, just a new entry on the features list based on set_online availability Dec 29 17:14:58 however, none of this is causing your problems ;) Dec 29 17:15:48 denkenz: no. it's just 'cause you told me to use ofono instead of pygsmd because more modems are supported. Dec 29 17:16:04 pygsmd supports one of 3 here, ofono zero ;) Dec 29 17:16:05 lol Dec 29 17:16:56 * balrog-k2n has attempted, but it was before Online was added :) Dec 29 17:17:14 calypso was working awesomely when I told you this btw Dec 29 17:17:34 but since no one was really interested in it, it has suffered bit rot Dec 29 17:18:07 huawei driver needs to be rewritten, but it should work now with patches from lucas Dec 29 17:18:44 For the n900 our Nokia folks assured me it received lots of testing ;) Dec 29 17:25:09 about the huawei, i have a real strange behaviour: a AT+CFUN=1 is answered with ERROR, just that, no more :/ Dec 29 17:26:33 i am not sure why that happened, i had that in a terminal too, it seems the modem gets into a strange state somehow. does someone know more about such a thing? Dec 29 17:28:50 denkenz: is someone already working on the rewrite of the huawei driver? Dec 29 17:29:28 emdete: it happened once with me Dec 29 17:29:42 emdete: not sure how i fixed that Dec 29 17:29:43 demarchi: any idea when? Dec 29 17:29:59 emdete: just removed the SIM, put it again Dec 29 17:30:04 and it was working Dec 29 17:30:30 demarchi: does the modem allow sim replacement when powered? Dec 29 17:30:30 when?? humn... 2 weeks ago i think Dec 29 17:30:36 no Dec 29 17:30:57 so powerdown by ofono is sufficient? or a reboot? Dec 29 17:31:05 it's a usb dongle, i removed it then removed the sim Dec 29 17:31:18 i can't, its inside ;) Dec 29 17:31:20 emdete: it simply stopped to answer anything Dec 29 17:31:23 any command Dec 29 17:31:35 hm, no, it's talking fine to me/ofono :D Dec 29 17:31:42 so, even shutdown was not possible Dec 29 17:32:03 +CFUN=6 or something? Dec 29 17:32:06 if it's inside, a reboot should be fine Dec 29 17:33:30 demarchi: i wonder why these devs don't have a rfkill :/ Dec 29 17:39:35 you should be able to reset any usb or pci device using /sys i think Dec 29 17:40:28 balrog-k2n: how? Dec 29 17:40:52 demarchi: i rebooted, replaced sim, redid all, still ERROR on CFUN Dec 29 17:40:59 * balrog-k2n wonders what device to try it on.. Dec 29 17:44:16 you should have an em770 pcix card Dec 29 17:46:09 emdete: echo 0 into /enable does it for me Dec 29 17:46:20 some devices also have .../power/state Dec 29 17:47:01 balrog-k2n: :D yes, sure, the magic part is: how do i determine the path :) Dec 29 17:47:26 udev gives you all the variable elements of the path Dec 29 17:50:13 hm, its usb: lsusb shows 12d1:1404 Dec 29 17:50:19 balrog-k2n: ? Dec 29 17:52:02 emdete: ? Dec 29 17:52:06 it's in /sys, look it up Dec 29 17:53:17 balrog-k2n: find /sys|wc gives 9100, no clue what to look for. Dec 29 18:03:01 hrm... got ofono 0.37 on my n900 running debian sid (udev 164) but list-modems still doesnt give me any output - whom to contact about that issue? any ideas how to debug that? Dec 29 18:05:28 a post on the mailing list should be your first step Dec 29 18:05:41 what information should i provide? Dec 29 18:05:58 the usual, your configuration, udev settings, etc Dec 29 18:10:38 denkenz, josch: can the issue be related to udev rule change Dec 29 18:11:52 Jeevaka: i use the latest .rules file and was only trying it out in the last few days, meaning that i wasnt trying it out before so i cannot say anything about something having changed Dec 29 18:12:17 Jeevaka: if you have a .rules file for me - pass it over :) Dec 29 18:16:16 demarchi: so you ERROR on CFUN was related to hw more or less, right? i assume mine is somehow related to wrong sequence of or missing commands... do you have an idea how to proceed? Dec 29 18:19:09 josch: udev rules file comes with the ofono ./plugins/ofono.rules Dec 29 18:19:31 emdete: right... i think yours is related to hw too Dec 29 18:19:55 josch: copy ofono.rules to the respective folder and start the ofono Dec 29 18:20:53 balrog-k2n, denkenz: ping Dec 29 18:22:44 emdete: i'm not sure what to do... for me it was just a matter of turning the device off and on again Dec 29 18:23:18 Jeevaka: my /lib/udev/rules.d/97-ofono.rules is exactly the same as ./plugins/ofono.rules and i not only tried to restart udev and ofono but also rebooted without any success Dec 29 18:23:18 <\marco> hi all Dec 29 18:23:25 emdete: can you give the commands "by hand" to your modem? Dec 29 18:23:38 emdete: is it asking for PIN? Dec 29 18:24:03 try: AT+CPIN? Dec 29 18:24:39 demarchi: works just fine. pin entry works too Dec 29 18:25:01 <\marco> I'm a newbie to ofono. I'm trying to use the hfp with my mobile ( I'm following the wiki page) but when I launch /usr/lib/ofono/test/enable-modem /hfp/[blabla] I get Dec 29 18:25:08 <\marco> ofonod[23851]: plugins/hfp.c:hfp_connect_reply() Connect reply: Method "Connect" with signature "" on interface "org.bluez.HandsfreeGateway" doesn't exist Dec 29 18:26:42 <\marco> I'm on gentoo linux ( kernel 2.6.32 ) and I'm using ofono 0.36 with bluez stack 4.75 Dec 29 18:27:07 josch: then as denkenz said post with all the configuration settings, udev to the mailing list :) Dec 29 18:27:42 <\marco> oh.. and dbus 1.4.1 Dec 29 18:28:23 Jeevaka: what configuration settings are important - i didnt change any configuratio Dec 29 18:28:35 make sure your bluez includes support for hfp Dec 29 18:29:10 <\marco> denkenz, mhm how can I check? Dec 29 18:29:22 see audio.conf in /etc/bluez? Dec 29 18:29:45 josch: have you tried with 0.36? Dec 29 18:29:47 demarchi: everything's fine but the CFUN command. Dec 29 18:29:55 Jeevaka: yes, same situation Dec 29 18:32:09 <\marco> denkenz, I've put Enable=Gateway in audio.conf Dec 29 18:32:10 hmm, then I dont have any idea. akiniemi_: any comments? Dec 29 18:32:14 <\marco> already :) Dec 29 18:35:29 Then you also might need HFP=True Dec 29 18:36:12 <\marco> denkenz, oh :) let me try Dec 29 18:36:39 <\marco> denkenz, under [Headset] section? Dec 29 18:36:49 I guess so, its been a while Dec 29 18:37:03 <\marco> mhm already have HFP=True Dec 29 18:37:18 denkenz: about the Retry Counter... do you think it's important to cover all that use cases? Dec 29 18:37:38 denkenz: afair, they do not cause the counter do be decremented Dec 29 18:37:47 demarchi: They do Dec 29 18:38:09 demarchi: If you try to disable the pin and provide the wrong pin, you can actually lock yourself out Dec 29 18:38:25 <\marco> I've to go, thanks anyway :) Dec 29 18:38:40 <\marco> bye! ^_^ Dec 29 18:38:51 denkenz: even if it's currently unlocked? Dec 29 18:39:44 yep Dec 29 18:40:26 denkenz: so maybe i'll have to touch these methods... because there's no place i can get the information of what pin was decremented Dec 29 18:41:04 other approach is to show all the counters, but i don't think this is desirable, is it? Dec 29 18:41:14 So the way I would do this is maybe modify the driver function to take the pin to query as input Dec 29 18:42:13 And show PinRetries always, but only for PIN1 for now Dec 29 18:42:21 Others are probably pointless Dec 29 18:42:52 humn... so, the signal propertyChanged will not be always right Dec 29 18:43:24 why not? you can query PinRetries after every failed attempt Dec 29 18:43:27 e.g. if i call unlock() three times, i'll receive no signal... yet, i'll be locked out Dec 29 18:44:12 yeah, but then what's the purpose of the signal if i have to query that property? Dec 29 18:44:32 so e.g. UnlockPin("pin", "1234") -> Error -> query_pin_retries("pin") -> PropertyChanged("PinRetries", 2) Dec 29 18:45:15 same as for EnterPin() Dec 29 18:45:20 so, is the following behavior right? Dec 29 18:45:48 UnlockPin("pin", "1234") -> Error -> query_pin_retries("pin") -> PropertyChanged("PinRetries", 2) -> query_pin_retries("puk") -> PropertyChanged("PinRetries", 10) Dec 29 18:46:41 ah I see your point Dec 29 18:47:14 with what you say, PinRetries is more a method than a property Dec 29 18:47:29 yes, we're overloading the meaning a bit Dec 29 18:47:47 Ok, so for now lets do it this way: Track the pin retries / pin Dec 29 18:48:00 it's meaningless as a property, as i don't know which counter it represents Dec 29 18:48:10 However, show PinRetries property only when the PinRequired != none Dec 29 18:48:30 demarchi: do you know the command at^rfswitch ? Dec 29 18:50:13 actually, maybe we should make PinRetries into a dict Dec 29 18:50:13 emdete: i never used it Dec 29 18:50:25 And show all Pin retries Dec 29 18:50:35 demarchi: it seems to be needed... after that cfun works Dec 29 18:51:02 emdete: good to know Dec 29 18:51:16 demarchi: can i fire an arbitrary command into the modem via ofono? Dec 29 18:51:43 emdete: dunno, denkenz ^? Dec 29 18:52:03 emdete: nope Dec 29 18:53:05 denkenz: a dict with pin_type: retry_counter? Dec 29 18:53:56 so e.g. PinRetries -> [ {"pin", 3}, {"puk", 10} ] Dec 29 18:54:02 maybe even call it Retries Dec 29 18:54:28 ok... this doesn't seem difficult to change Dec 29 18:55:26 however, i'll have to fire a check_pin() in unlock(), change_pin(), etc Dec 29 18:55:42 otherwise i'll not be able to signal the property change Dec 29 18:55:53 sounds reasonable Dec 29 18:57:24 yeah, that should be ok Dec 29 19:22:40 Hi. I'm relatively new to OFono, and I'm currently working with using the ISI/USB connectivity mode of Nokia smartphones for another project. I've been looking around the mailing lists and other Web resources for a while; but does anyone have a brief idea of the "state of play" as far as GPRS, SIM Authentication and utilisation of SIM Toolkit applications via ISI is concerned? Thanks. Dec 29 19:23:58 demarchi: that was it. the em770 needs that command. i issued it in another channel, run my script and everything is fine. Dec 29 19:24:13 demarchi: should this go into ofono? Dec 29 19:29:59 i found also a way to power-cycle/reboot the modem. is there something like that in ofono? Dec 29 19:33:46 if your modem needs some command for a proper powerup then yes it probably belongs in ofono Dec 29 19:34:34 vmlemon_: GPRS is supported on ISI, however current ISI driver does not support sim toolkit and it is not possible to do so on the n900 Dec 29 19:36:31 denkenz, balrog-k2n: would like to discuss about Browser termination event download Dec 29 19:37:43 yes? Dec 29 19:37:50 Thanks denkenz! It looks like I was able to create a GPRS session, after some prodding around, a few seconds ago. :) Dec 29 19:38:51 denkenz: is gprs supported on huawei too? how does that work? does ofono start pppd? Dec 29 19:39:06 On the other hand, I'm sure that I'm supposed to see the network operator name (O2 UK, in my case) in the output of "test-network-registration" in addition to the signal strength... Dec 29 19:39:29 emdete: oFono runs its own userspace ppp stack Dec 29 19:39:31 (Instead, I only see empty quotation marks, with the latest code from the SCM). Dec 29 19:39:57 Not a big deal though. Dec 29 19:40:53 denkenz: planning to provide a new DBus interface EventDownload Dec 29 19:42:03 in stkagent Dec 29 19:43:11 denkenz: so gprs should work with huawei just fine? Dec 29 19:43:15 err, why? Dec 29 19:43:27 emdete: works on other huaweis Dec 29 19:43:33 dunno if yours is special ;) Dec 29 19:44:20 do you see any other option? Dec 29 19:45:09 I suspect that LaunchBrowser needs its own dedicated Agent Dec 29 19:45:26 And when the agent exits, then the BrowserTermination event is sent Dec 29 19:45:40 or something equally evil Dec 29 19:46:00 denkenz: how is suspend/resume supported? Dec 29 19:46:41 on huawei? who knows, their docs don't ever mention suspend / resume Dec 29 19:46:58 remember its a pure datacard modem, no suspend / resume features should be enabled Dec 29 19:52:36 then in that case how are we going to do for other event downloads like language selection, idle screen available Dec 29 19:58:15 denkenz: so what's the plan, if a modem doesn't support it? switch off & on later? is there is sig to re-send the pin? Dec 29 19:59:58 Jeevaka: I thought we agreed we aren't supporting them Dec 29 20:00:57 even launch browser, if implemented according to the spec, makes about zero sense Dec 29 20:01:20 oops. did we agreed for language selection as well Dec 29 20:02:30 I'm fine dropping Language selection Dec 29 20:02:38 even if we need it, then it should be a method call Dec 29 20:03:37 may be I used a wrong word. what i meant is to introduce a DBus method EventDownload Dec 29 20:03:45 yeah, no ;) Dec 29 20:04:32 planning to add the EventDownload as part of stkagent interface Dec 29 20:05:22 "Language" and value part e.g."English" or language code Dec 29 20:06:39 as I said, no EventDownload method Dec 29 20:06:46 not doing it that way Dec 29 20:07:05 denkenz: did you see my fix for cnap and the colr colp renaming? Dec 29 20:08:09 I'm almost open to a method for the language selection, but IdleScreen and UserActivity stuff is not going to be happening Dec 29 20:09:05 UserActivity definitely not Dec 29 20:10:10 Since I dont see the actual case with IdleScreen, I'm ok with whatever you decide Dec 29 20:11:36 lets see if we can get away without LanguageSelection event Dec 29 20:11:42 denkenz: is there sample code to extablish a gprs connection? Dec 29 20:11:52 if not, then we add some form of property / method for that one Dec 29 20:12:05 emdete: test/activate-context? Dec 29 20:12:28 Jeevaka: for Launch Browser we do something else, since we really have 1 proactive command and 2 events Dec 29 20:12:39 The Browser Status event is wholly stupid Dec 29 20:12:55 don't even know how it can be used if you have multiple sessions open Dec 29 20:13:44 demarchi: I haven't looked at those yet Dec 29 20:17:49 denkenz: does gprs need some udev rule to work? the script gets an timeout btw. log is silent Dec 29 20:20:01 nope Dec 29 20:20:50 run list-modems and tell me whether ConnectionManager interface is up? Dec 29 20:22:22 Then run list-contexts and tell me if your context is provisioned properly Dec 29 20:22:32 if not, run create-internet-context with your apn/user/pass Dec 29 20:22:38 Then try activate-context again Dec 29 20:23:33 connman is there Dec 29 20:23:35 If you still have trouble, send your wetab to me so I can de-solder that modem, throw it out of the window and put in a proper one ;) Dec 29 20:24:08 denkenz: you have to do that for thousands. if you like i tell the company you will help out here. Dec 29 20:24:55 denkenz: remember that your argument for switching to ofono was that it supports more modems and will save my time Dec 29 20:25:43 and it does, but then it looks like your modem is special Dec 29 20:26:20 I've done live demos with voice on huaweis at conferences Dec 29 20:26:24 so its not like they don't work Dec 29 20:27:03 denkenz: i never said so. i just want to help that one more works flawlessly Dec 29 20:27:12 so apn is set fine Dec 29 20:27:26 Error activating /huawei0/context1: org.ofono.Error.InProgress: Operation already in progress Dec 29 20:27:37 says activate-context Dec 29 20:28:21 so whenever you get an InProgress it means that the driver never replied with a success / failure Dec 29 20:28:45 This means that either the command was never sent to the modem, or the parser screwed up, or the modem never replied Dec 29 20:28:52 is the port you're using for ppp correct? Dec 29 20:29:24 21:15 emdete> denkenz: does gprs need some udev rule to work? the script gets an timeout btw. log is silent Dec 29 20:29:44 so how do i set the port correctly? Dec 29 20:30:15 shrug, see what ports ofono selects for ppp Dec 29 20:30:22 how? Dec 29 20:30:32 udev rule? Dec 29 20:30:52 then there's gatchat/gsmdial that runs basic ppp Dec 29 20:31:01 see whether gsmdial works on those ports Dec 29 20:31:21 lets start from the beginning: how is gprs supposed to work? Dec 29 20:31:52 how does ofono determine 'the correct port'? Dec 29 20:32:17 where can i see which port was selected? (there is no trace of ppp in syslog, debug is on) Dec 29 20:32:30 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1408", ENV{OFONO_IFACE_NUM}=="02", ENV{OFONO_HUAWEI_TYPE}="Modem" Dec 29 20:32:30 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1408", ENV{OFONO_IFACE_NUM}=="00", ENV{OFONO_HUAWEI_TYPE}="Pcui" Dec 29 20:32:45 So the Modem port gets assigned to ppp, PCUI port gets assigned to the rest Dec 29 20:33:41 the modem port is not used in any other way? Dec 29 20:35:32 nope Dec 29 20:36:07 its all in plugins/huawei.c Dec 29 20:36:39 what is in plugins/huawei.c? Dec 29 20:37:44 the port assignments Dec 29 20:38:47 but if the one is used for ppp it's blocked for all other access, right? Dec 29 20:40:43 yep Dec 29 20:44:31 i wonder why it doesn't logg anyhting Dec 29 20:47:20 it could be that port we're selecting is not actually for AT commands Dec 29 20:47:37 but is e.g. qcdm (qualcomm proprietory) Dec 29 20:48:14 in that case there will be no log ? Dec 29 20:48:32 perhaps Dec 29 20:49:05 though if you see absolutely nothing in the log and OFONO_AT_DEBUG is on, that means that port is not even firing select for reads Dec 29 20:49:13 err writes Dec 29 20:49:24 so that's bad Dec 29 20:49:51 gsmdial should let you diagnose this quickly Dec 29 20:50:03 it even supports dual tty setup Dec 29 20:57:23 so how do i use gsmdial? Dec 29 20:57:51 gsmdial --help is your friend Dec 29 21:00:30 so e.g. something like gsmdial -n /dev/ttyUSB0 -m /dev/ttyUSB1 -c 1 -a "foo.apn" Dec 29 21:08:01 hm, help isn't mich helpful, it doesn't tell what for this tool is at all... what does it do? dial my grandma by gsm? hm... Dec 29 21:09:26 umm, its nearly identical to wvdial Dec 29 21:09:36 basically establishes a gprs context Dec 29 21:11:07 stopps after Modem: > AT+CGDATA="PPP",1\r Dec 29 21:12:03 but has alot of output before... Dec 29 21:13:24 Try running with the legacy mode, -l Dec 29 21:13:44 however, it looks like the port you're using for modem does not support ppp Dec 29 21:22:50 ah, -l means this *99** dialing... Dec 29 21:24:04 okay, i used wrong ports, now i fixed that and ppp comes up Dec 29 21:25:03 and without -l its fine too Dec 29 21:25:57 so -n is Pcui and -m is Modem, right? Dec 29 21:31:45 yep Dec 29 21:40:25 denkenz: still no-op Dec 29 21:41:28 i wonder why not one log line is issued Dec 29 21:42:42 that seems strange Dec 29 21:43:08 the code from gsmdial was essentially copy-paste to the ppp gprs-context driver Dec 29 22:30:41 denkenz: difference is at least that gsmdial logs failure... Dec 29 22:31:21 denkenz: so what is the plan /if/ it works: a ppp0 shows up? how is ip/route/dns configuration triggered? Dec 29 22:31:45 connman Dec 29 22:31:57 ......and without? Dec 29 22:32:06 homework assignment? :) Dec 29 22:32:13 you can try test/process-context-settings Dec 29 22:32:29 so how is ip/router/dns information transported? Dec 29 22:32:41 dbus to connman? Dec 29 22:33:49 may that be a problem it connman is not installed? Dec 29 22:34:40 how is connman not installed on a meego device? Dec 29 22:34:51 but anyway, see the Settings property in doc/connman-api.txt Dec 29 22:35:22 a) there is no full meego in a wetab os. b) there is no meego at all on /my/ wetab ;) Dec 29 22:37:07 denkenz: so there are dbus signals fired? Dec 29 22:37:35 yep, you get a PropertyChanged(Settings, foo) Dec 29 22:37:44 where Settings has a dict with all your networking info Dec 29 22:37:56 again, the docs actually do explain this Dec 29 22:38:00 okay, that's great & means: i don't need connman at all.. Dec 29 22:38:47 and there is a ppp0 and the signal receiver has to catch the conf & apply, right? Dec 29 22:39:00 yep Dec 29 22:39:06 nice! **** ENDING LOGGING AT Thu Dec 30 02:59:58 2010