**** BEGIN LOGGING AT Tue Feb 01 02:59:57 2011
Feb 01 08:33:44 <Jeevaka> akiniemi: ping
Feb 01 08:38:13 <akiniemi> Jeevaka: pong
Feb 01 08:40:12 <Jeevaka> examples/nettime.c is expecting the dst to be in seconds whereas isimodem and atmodem dst is filled in hours
Feb 01 08:42:07 <akiniemi> Jeevaka: the doc in types.h says it should be in seconds, so the drivers are wrong here
Feb 01 08:42:27 <akiniemi> Jeevaka: good catch ;)
Feb 01 08:43:15 <Jeevaka> i will go ahead and deliver the patch then
Feb 01 08:43:37 <akiniemi> Jeevaka: thanks
Feb 01 09:33:27 <Jeevaka> akiniemi: ping
Feb 01 10:03:51 <emdete> holtmann: i did what you recommended yesterday for gprs with the calypso. now it shows a org.ofono.ConnectionManager but activating gives an "org.ofono.Error.NotImplemented: Implementation not provided". what did i miss?
Feb 01 10:10:16 <holtmann> That normally means you have no GPRS context attached to the GPRS atom.
Feb 01 10:11:06 <holtmann> Show me your patch.
Feb 01 10:13:21 <emdete> http://mister-muffin.de/p/w2Fm
Feb 01 10:14:45 <holtmann> This looks fine.
Feb 01 10:14:55 <holtmann> You do have TUN/TAP kernel module loaded?
Feb 01 10:15:29 <holtmann> You do not need to store gprs and gc in calypso_data btw.
Feb 01 10:15:47 <holtmann> Only the stupid modems that hangup the line after PPP disconnect need that.
Feb 01 10:16:00 <emdete> i copied from huawei ;)
Feb 01 10:16:07 <holtmann> That is one of the stupid ones ;)
Feb 01 10:16:10 <emdete> :D
Feb 01 10:16:26 <holtmann> 	if (gprs && gc)
Feb 01 10:16:26 <holtmann> 		ofono_gprs_add_context(gprs, gc);
Feb 01 10:16:39 <holtmann> STE for example keeps it local in post_online.
Feb 01 10:16:47 <holtmann> Which is post_sim for Calypso.
Feb 01 10:17:13 <fdanis> holtmann: did you take a look to the v4 of bluetooth server support patch ?
Feb 01 10:17:21 <holtmann> Can you run ofonod with OFONO_AT_DEBUG=1 and also -d '*gprs*'.
Feb 01 10:17:24 <emdete> the if is needed? can it be NULL?
Feb 01 10:17:48 <holtmann> We kept doing that check. In theory under certain moon phases it could be potentially be NULL.
Feb 01 10:18:06 <holtmann> Likelyhood is almost zero actually.
Feb 01 10:18:10 <holtmann> fdanis: I have not.
Feb 01 10:18:45 <emdete> dropping a log-line would be nice in that case...
Feb 01 10:18:52 <emdete> assuming it's an error, right?
Feb 01 10:18:57 <holtmann> emdete: If the /dev/net/tun device is not present we should log an error.
Feb 01 10:19:17 <emdete> there was nothing logged. i use OFONO_AT_DEBUG and --debug all the time
Feb 01 10:19:33 <holtmann> Are you sure. That is weird.
Feb 01 10:19:51 <emdete> so -d '*gprs*' is --debug but filtering, right?
Feb 01 10:19:58 <holtmann> Yes, that is a filter.
Feb 01 10:20:06 <holtmann> Based on filenames.
Feb 01 10:20:18 <holtmann> Print only DBG statement where filename matches *gprs*
Feb 01 10:20:36 <holtmann> Helps you to stay sane ;)
Feb 01 10:20:51 <emdete> okay. i loaded tun, restarted ofono, issue my script...
Feb 01 10:21:09 <holtmann> If you run with OFONO_AT_DEBUG=1 then you need to see at least AT commands for GPRS attach and also for ATD.
Feb 01 10:21:27 <holtmann> CGDATA actually ;)
Feb 01 10:21:33 <emdete> thing is: there seems to be some timing condition, i often get that error with other dbus requests and after a while  it works :/
Feb 01 10:21:33 <Gzajac> holtmann: did you look at the powered_watches patch?
Feb 01 10:21:48 <holtmann> Gzajac: I have not. I leave that to Denis.
Feb 01 10:21:52 <Gzajac> ok
Feb 01 10:22:27 <holtmann> emdete: Maybe the Freerunner hardware is just bad.
Feb 01 10:22:38 <emdete> holtmann: maybe? harhar...
Feb 01 10:22:47 <holtmann> Or it needs longer to attach, but then you should get not attached error back.
Feb 01 10:22:48 <emdete> nice, it works. :/
Feb 01 10:22:57 <holtmann> Hah. Sweet.
Feb 01 10:23:16 <emdete> but maybe there is a timing issue in ofono?
Feb 01 10:23:43 <holtmann> There should not be.
Feb 01 10:23:54 <holtmann> We have been using this on almost every single GSM device on the planet.
Feb 01 10:24:08 <holtmann> However you have to wait to get attached first.
Feb 01 10:25:20 <holtmann> emdete: Maybe our error codes are wrong.
Feb 01 10:25:51 <holtmann> emdete: You do know that you can run monitor-ofono Python test script to see all signals coming from oFono.
Feb 01 10:25:59 <emdete> i can give you my script too, so you can check. it runs fine on three other devs
Feb 01 10:26:08 <emdete> yes, i know
Feb 01 10:26:43 <holtmann> I am using activate-context and ConnMan. Both are just fine.
Feb 01 10:26:52 <emdete> with calypso? :)
Feb 01 10:27:05 <holtmann> No idea. With all other modems that I have.
Feb 01 10:27:16 <holtmann> I stop testing with the Calypso to be honest.
Feb 01 10:27:47 <emdete> these scripts have a problem: if you trigger them by hand you introduce pauses on between. these allow ofono/modem to settle down. if you fire the same in one script you get this error quite often
Feb 01 10:28:22 <holtmann> That is why I added tools/auto-enable. We can add a tools/auto-activate for GPRS here if needed.
Feb 01 10:28:30 <emdete> i just have one script, works syncron. it loops getting props&sleeps until a state is reached...
Feb 01 10:28:40 <holtmann> Essentially that is what ConnMan does.
Feb 01 10:28:47 <emdete> i wrote one... i will check tools/auto-enable
Feb 01 10:29:19 <holtmann> That said, we had issues with certain modem hardware where the SIM was not ready even if the modem told us.
Feb 01 10:29:57 <holtmann> I am always open for more test scripts.
Feb 01 10:30:03 <emdete> yes, i know, i have a huawei of that kind too ;)
Feb 01 10:30:30 <holtmann> Freerunner is the most slow hardware I have seen in a while. Maybe because of that it exposes certain behavior that we don't see in other modems.
Feb 01 10:30:32 <emdete> holtmann: maybe one could invent a more module-like aproach for the scripts?
Feb 01 10:30:35 <fdanis> holtmann: when do you think you can have a looki to it ?
Feb 01 10:31:02 <holtmann> fdanis: Hopefully later today. Still need to sync with Denis.
Feb 01 10:31:19 <fdanis> holtmann: ok, thanks
Feb 01 10:31:24 <holtmann> emdete: Yeah, good idea, but until someone does the hard work, I don't think that happens.
Feb 01 10:31:40 <emdete> hard work? python is soft work always ;)
Feb 01 10:31:55 <holtmann> I am particular lazy with Python.
Feb 01 10:33:01 <emdete> that's what python is for, right?
Feb 01 10:38:47 <Jeevaka> akiniemi: ping
Feb 01 10:40:21 <emdete> holtmann: but generally speaking: there is interest in improving the scripts?
Feb 01 10:40:53 <holtmann> If I don't have to do it, then yes ;)
Feb 01 10:41:27 <emdete> holtmann: he, you have to test 'em ;)
Feb 01 10:41:50 <holtmann> Nah, I just complain if you break something.
Feb 01 10:44:00 <emdete> :D okay. another topic: how is mms supported? ive seen test/create-mms-context. i sended an mms to an ofoned device and did not receive any signal from ofono but ofono loggs that the sms was received. ...
Feb 01 10:59:48 <emdete> holtmann: you don't like mms? :)
Feb 01 11:01:15 <holtmann> emdete: MMS is not done inside oFono.
Feb 01 11:01:35 <holtmann> It just provides the basics. Like MMS bearer configuration. And WAP Push notification.
Feb 01 11:01:50 <emdete> does it decode the pdu? 
Feb 01 11:01:52 <holtmann> You need a MMS daemon or application that then uses these.
Feb 01 11:02:05 <emdete> is there one avaiable?
Feb 01 11:02:13 <holtmann> Nope. It gives you the raw WAP Push PDU. Check test/test-push-notification script.
Feb 01 11:53:56 <tomaszgr> Hi all, quick question about coding style, we are trying to align enum variables values with tabs, what tab size should we use, 4 or 8? if values are in line with 4 than they are not with 8 and opposite, do we bother about this much?
Feb 01 11:54:05 <tomaszgr> maybe we should use just spaces here?
Feb 01 11:54:22 <holtmann> 8.
Feb 01 11:54:26 <holtmann> And no spaces.
Feb 01 11:54:30 <tomaszgr> thanks
Feb 01 11:55:00 <holtmann> It is essentially kernel coding style with the additions/exception outlined in doc/coding-style.txt
Feb 01 11:55:11 <holtmann> If something is unclear. Add it there as another rule.
Feb 01 11:55:32 <tomaszgr> and this is an answer for my next question
Feb 01 11:55:38 <tomaszgr> thanks again
Feb 01 11:56:26 <holtmann> We are something like 98% consistent throughout the code base. So you can just take that as examples.
Feb 01 11:56:44 <holtmann> However there are cases where wrong style slipped in or is just legacy from the early days.
Feb 01 11:56:50 <holtmann> Patches for fixing that are always welcome.
Feb 01 11:59:00 <tomaszgr> yep, we are just correcting one while slightly changing, thats why asking
Feb 01 12:47:12 <emdete> holtmann: another thing with a huawei modem. i added some code to enable that model. this is running unconditional and would fire for all models which is probably a bad idea. question is: how can i do that conditional for that exact model?
Feb 01 12:47:55 <holtmann> You need to read the model during huwei_enable.
Feb 01 12:48:01 <holtmann> HSO and MBM does that as well.
Feb 01 12:49:28 <Jeevaka> holtmann: remi's patch is implementation for generic pin retry counter
Feb 01 12:49:47 <emdete> hm, isn't the model read anyway and somewhere stored?
Feb 01 12:49:54 <holtmann> Yes. Seems newer specs have +CPINR.
Feb 01 12:50:12 <holtmann> Jeevaka: Let me get that one applied and then you can re-base.
Feb 01 12:50:31 <Jeevaka> holtmann: ok, got it
Feb 01 12:54:07 <holtmann> Jeevaka: Patch looks fine. Just re-base it and we can apply it.
Feb 01 12:54:12 <Jeevaka> holtmann: new command is optional, dont know whether all the modem vendors will move to the new one
Feb 01 12:54:38 <holtmann> That is fine.
Feb 01 12:54:49 <holtmann> We have the specific code for modem where we know the vendor command.
Feb 01 12:54:57 <holtmann> For the other we try the other one and fail. So bad luck.
Feb 01 12:55:10 <holtmann> If some modems heavily misbehave, then we have to see.
Feb 01 12:55:21 <holtmann> But you never know until you try ;)
Feb 01 12:56:16 <Jeevaka> agree
Feb 01 12:58:18 <holtmann> ofonod[16414]: Device: > AT+CPIN?\r
Feb 01 12:58:18 <holtmann> ofonod[16414]: Device: < \r\n+CPIN: READY\r\n\r\nOK\r\n
Feb 01 12:58:18 <holtmann> ofonod[16414]: Device: > AT+CPINR\r
Feb 01 12:58:18 <holtmann> ofonod[16414]: Device: < \r\nERROR\r\n
Feb 01 12:58:19 <holtmann> ofonod[16414]: Querying remaining pin retries failed
Feb 01 12:58:21 <emdete> holtmann: can i access the modem model somewhere?
Feb 01 12:58:23 <holtmann> This is the downside of that patch.
Feb 01 12:58:57 <holtmann> emdete: You need to find the command that does it for your modem. It is highly vendor specific. Huawei has such a command.
Feb 01 12:59:06 <holtmann> And also a bunch of other magic ones.
Feb 01 13:00:28 <holtmann> emdete: Which Hauwei device is this?
Feb 01 13:01:08 <emdete> holtmann: most of the modems i know respond correctly to +CGMM ... it's the em770something 
Feb 01 13:01:24 <holtmann> em770 comes in various alterations.
Feb 01 13:01:53 <holtmann> We do read the +CGMM, but you need it earlier anyway. So you might have to read it in hauwei_enable().
Feb 01 13:02:16 <emdete> oups... mine needs a ^RFSWITCH=1 beforeoperating correctly... :/
Feb 01 13:02:16 <holtmann> Check MBM. They just read AT+CGMM
Feb 01 13:02:42 <emdete> okay. i just wanted to avoid useless AT commands it the data is already there
Feb 01 13:02:46 <holtmann> Can you just not ^RFSWITCH=? and ^RFSWITCH?
Feb 01 13:02:52 <holtmann> And in case it is disabled, enable it.
Feb 01 13:03:06 <holtmann> We do this for USSDMODE one of the newer ones.
Feb 01 13:03:10 <emdete> don't know what other modems/huaweis do in thet case
Feb 01 13:03:26 <emdete> and i switch it off in de-activate
Feb 01 13:03:50 <holtmann> Check if ^RFWSITCH is supported with =? and then always do it.
Feb 01 13:04:20 <emdete> okay.
Feb 01 13:04:27 <holtmann> We can't give you any model number since the modem plugin is responsible for the init. The atoms are only created after modem init.
Feb 01 13:04:48 <holtmann> And worst case you read it twice. If the modem is so fucked up, so be it.
Feb 01 13:04:59 <holtmann> But I think you don't need it in your case.
Feb 01 13:08:58 <akiniemi> Jeevaka: pong
Feb 01 13:09:12 <Jeevaka> s
Feb 01 13:09:57 <Jeevaka> akiniemi: whats the point in checking the dst value with NET_INVALID_TIME when the values it can take is 0,1 or 2
Feb 01 13:10:22 <akiniemi> Jeevaka: the network may not provide the value at all
Feb 01 13:11:02 <Jeevaka> isimodem then sends NET_INVALID_TIME when it doesn't receive the info from network
Feb 01 13:11:14 <akiniemi> Jeevaka: nod
Feb 01 13:51:32 <Gzajac> padovan: ping
Feb 01 13:57:48 <padovan> Gzajac: pong
Feb 01 13:59:04 <Gzajac> I have one question concerning the way you are creating DUN emulator
Feb 01 14:00:04 <Gzajac> Normally we need to have the modem powered ON to create the emulator? Creating emulator when GPRS atom is creating is a bit late, isn't it ?
Feb 01 14:02:25 <padovan> a bit late for what?
Feb 01 14:04:25 <Gzajac> I mean when you have some AT command like CGMI or CFUN... to be sent the GRPS atom is not necessary or maybe I miss something
Feb 01 14:04:45 <Gzajac> so you need your AT emulator to be created
Feb 01 14:10:56 <padovan> Are those commands related to DUN?
Feb 01 14:11:33 <Gzajac> yes CGMI is in DUN spec
Feb 01 14:11:43 <Gzajac> CGMM also
Feb 01 14:11:53 <Gzajac> GMI not CGMI sry
Feb 01 14:12:18 <Gzajac> GMM not CGMM :)
Feb 01 14:16:08 <padovan> Bluetooth DUN will only be available for a client connection when the records are added to BlueZ SDP, so no problem if it is created when the GPRS goes online
Feb 01 14:17:10 <padovan> it's the way Denis suggested me. It' s better than modify modem.c
Feb 01 14:17:47 <Gzajac> BlueZ SDP can't be created before the modem is online?
Feb 01 14:18:19 <Gzajac> I agree it is not good to modify modem.c
Feb 01 14:19:13 <Gzajac> but adding generic powered_watches like online_watches could be used also
Feb 01 14:19:33 <Gzajac> not only for emulator but maybe for other future services
Feb 01 14:20:57 <padovan> then we create these watches when we have the future services. DUN emulator doesn't justify that to me.
Feb 01 14:24:59 <Gzajac> so how could we create emulator when modem is enable ?
Feb 01 14:28:09 <padovan> By now we keep listen the GPRS service, but we can change that later if needed.
Feb 01 14:28:48 <padovan> And now we focus on the actual DUN Server implementation.
Feb 01 14:28:51 <Gzajac> ok
Feb 01 14:31:53 <fdanis> padovan: I thought that the Emulator will also be used for HFP AG
Feb 01 14:31:53 <fdanis> HFP AG will need to be accessible even if the phone is not online (registered on the network)
Feb 01 14:44:46 <padovan> fdanis: as I said, we can change that later if needed.
Feb 01 14:47:58 <demarchi> holtmann: where should ofono_call_init() be declared/defined?
Feb 01 14:48:23 <demarchi> i couldn't find any similar case in ofono's code
Feb 01 14:48:41 <demarchi> denkenz: ^
Feb 01 14:49:44 <demarchi> src/common.[hc]?
Feb 01 14:54:17 <padovan> can't we put it in voicecall.h?
Feb 01 14:57:46 <demarchi> padovan: humn... i don't think it fits there...
Feb 01 14:59:35 <padovan> I don't think it fits in common.h ;)
Feb 01 15:00:41 <padovan> demarchi: yeah, it doesn't fit in voicecall.
Feb 01 17:20:51 <holtmann> demarchi: Patches look good. If Denis has no further objections, I take care of apply them.
Feb 01 17:27:23 <denkenz> my only problem is with the placing of the function implementation
Feb 01 17:27:28 <denkenz> I'd rather see it in voicecall.c
Feb 01 17:28:07 <denkenz> but apply it anyway
Feb 01 17:28:10 <denkenz> not a big deal
Feb 01 17:31:12 <holtmann> Okay. Then I take care of it.
Feb 01 17:36:12 <demarchi> denkenz: humn... it looked weird to me, it'd be the only function with "namespace" ofono_call inside voicecall.c
Feb 01 17:36:40 <demarchi> but... no strong feelings about it
Feb 01 17:37:06 <denkenz> well in general I like to avoid including ofono public apis from non-atom files
Feb 01 17:37:23 <denkenz> Or putting in public implementations in there
Feb 01 17:37:30 <denkenz> but common is somewhat 'special' anyway
Feb 01 17:38:42 <denkenz> if it bugs me enough I'll fix it, it is fine for now
Feb 01 17:38:45 <demarchi> denkenz: ok... i saw there was already a ofono_uuid_to_str made that way, so i did the same (declared in include/types.h and implemented in src/common.c)
Feb 01 17:40:05 <denkenz> yeah, I know, I'm not happy about that one either
Feb 01 17:40:13 <demarchi> :-)
Feb 01 17:40:13 <denkenz> But then I can only blame myself ;)
**** ENDING LOGGING AT Wed Feb 02 02:59:58 2011