**** BEGIN LOGGING AT Thu Aug 12 02:59:57 2010
**** ENDING LOGGING AT Thu Aug 12 07:18:02 2010

**** BEGIN LOGGING AT Thu Aug 12 07:24:15 2010
**** ENDING LOGGING AT Thu Aug 12 07:26:10 2010

**** BEGIN LOGGING AT Thu Aug 12 07:28:14 2010
**** BEGIN LOGGING AT Thu Aug 12 08:22:14 2010
**** ENDING LOGGING AT Thu Aug 12 08:26:17 2010

**** BEGIN LOGGING AT Thu Aug 12 08:28:15 2010
**** ENDING LOGGING AT Thu Aug 12 09:08:57 2010

**** BEGIN LOGGING AT Thu Aug 12 13:58:16 2010
**** ENDING LOGGING AT Thu Aug 12 14:26:17 2010

**** BEGIN LOGGING AT Thu Aug 12 14:38:15 2010
**** BEGIN LOGGING AT Thu Aug 12 15:18:14 2010
**** BEGIN LOGGING AT Thu Aug 12 15:38:15 2010
**** BEGIN LOGGING AT Thu Aug 12 16:44:14 2010
**** ENDING LOGGING AT Thu Aug 12 17:22:21 2010

**** BEGIN LOGGING AT Thu Aug 12 17:34:15 2010
**** BEGIN LOGGING AT Thu Aug 12 19:12:16 2010
**** BEGIN LOGGING AT Thu Aug 12 20:08:15 2010
Aug 12 21:30:44 <sameo> denkenz: do you know if the dell 5530 == ST f3507g ?
Aug 12 21:31:02 <denkenz> sameo: I think so
Aug 12 21:31:37 <sameo> denkenz: and 5540 == f3607 I'd assume ?
Aug 12 21:31:49 <denkenz> That one I have no idea
Aug 12 21:32:04 <denkenz> I never actually got any of the dell cards
Aug 12 21:32:25 <denkenz> Easy way to tell is to activate a context
Aug 12 21:32:36 <denkenz> the F3607 defaults to ip, 3507 to dhcp
Aug 12 21:33:24 <sameo> denkenz: is that the main difference ?
Aug 12 21:33:37 <denkenz> There are other differences, but yeah
Aug 12 21:34:40 <sameo> ok, thx
Aug 12 21:51:03 <denkenz> balrog-k1n: FYI, we tested STK running on the F3507 (not MD300) and it worked sweetly
Aug 12 21:51:28 <denkenz> balrog-k1n: Even Send SMS worked ;)
Aug 12 21:52:38 <denkenz> Had some issues with the MD300 though :(
**** ENDING LOGGING AT Thu Aug 12 22:30:20 2010

**** BEGIN LOGGING AT Thu Aug 12 22:56:14 2010
Aug 13 00:51:18 <zhenhua> denkenz: i have a question about fix in gatchat
Aug 13 00:52:59 <zhenhua> if the chat io disconnect by modem, io_disconnect is called and struct at_chat will be destroyed.
Aug 13 00:54:01 <zhenhua> in g_at_chat_unref looks like we need to add some check like if (chat->parent == NULL) goto done;
Aug 13 00:54:23 <zhenhua> and we need to g_free(GAtChat) to avoid memory leak
Aug 13 01:12:20 <denkenz> zhenhua: Not following, at_chat is never destroyed directly, it is ref counted
Aug 13 01:12:56 <denkenz> e.g. phonesim_disconnected will set modem powered off (removes all atoms) and unrefs the final chat
Aug 13 01:22:12 <zhenhua> denkenz: i observe that the gatchat of huawei modem port will be closed after gprs context disconnected.
Aug 13 01:22:34 <denkenz> huawei driver has not been ported btw
Aug 13 01:22:41 <zhenhua> and that will cause GAtIO requests to disconnect
Aug 13 01:23:34 <zhenhua> huawei driver is sucks, it always crash my machine
Aug 13 01:24:37 <denkenz> lol
Aug 13 01:24:45 <zhenhua> anyway, i suggest to add such check in g_at_chat_unref. it has potiential risk, like chat->parent could be null
Aug 13 01:25:07 <zhenhua> we should ask huawei engineer to write drivers for us
Aug 13 01:25:14 <denkenz> parent can never be null actually
Aug 13 01:26:58 <zhenhua> btw, for MMS context, why we want to create a SOCKS5 proxy?
Aug 13 01:27:11 <zhenhua> a serial proxy like bluez did looks enough for me
Aug 13 01:27:27 <zhenhua> that's much simpler, isn't is
Aug 13 01:27:31 <zhenhua> isn't it?
Aug 13 01:28:08 <denkenz> No, because you want proper IP passthrough
Aug 13 01:28:44 <denkenz> serial proxy cannot handle multiple IP based protocols, etc
Aug 13 01:28:51 <denkenz> Two different things ;)
Aug 13 01:29:11 <zhenhua> more than one MMS clients?
Aug 13 01:29:35 <zhenhua> so it requires NAT?
Aug 13 01:33:08 <denkenz> in effect it is NAT
Aug 13 01:33:33 <denkenz> However, the reason we do this is because MMS contexts can have private IP ranges that clash with the rest of the system
Aug 13 01:33:56 <denkenz> So you either use namespaces or a proxy
Aug 13 01:34:04 <denkenz> namespaces are nasty, proxy less so
Aug 13 01:34:16 <zhenhua> i see. that looks reasonable for me
Aug 13 01:34:48 <zhenhua> i will first take look into IPv6 PPP. i have RFC 2472 on hand. ;-)
Aug 13 01:35:10 <zhenhua> the problem is I cann't test my code here.
Aug 13 01:35:25 <denkenz> Test ppp stack with pppd first
Aug 13 01:35:34 <zhenhua> okay
Aug 13 01:35:47 <denkenz> I test it here when you have something working
Aug 13 01:36:34 <zhenhua> okay
Aug 13 01:39:34 <zhenhua> do u know any modem support suspend/resume operation? like F3506 or huawei...
Aug 13 01:55:23 <denkenz> nope
Aug 13 01:55:29 <denkenz> Never seen one
Aug 13 01:56:56 <denkenz> See if the calypso / freerunner would do it
Aug 13 01:57:23 <denkenz> I suspect that none of the usb dongles will support such a command since they're not really voice enabled
Aug 13 01:57:48 <zhenhua> will do. actually, i couldn't run ofono inside freerunner. :-(
Aug 13 01:58:11 <denkenz> it works
Aug 13 01:58:14 <zhenhua> I need more study about hacking freerunner. ;-)
Aug 13 01:58:30 <denkenz> Download the NeoPhysis distro, comes with ofono
Aug 13 01:58:42 <zhenhua> oh... thanks!
Aug 13 01:58:48 <zhenhua> i am now still using SHR
Aug 13 02:25:23 <yang_office> denkenz: I have two questions on sms and mms separately. 1. oFono doesn't store sms, so how to store sms outside of oFono? Would the D-Bus APIs be enough, or we have to write a new history driver?
Aug 13 02:26:01 <denkenz> Er, the system integrator provides a history plugin
Aug 13 02:26:12 <denkenz> What it does and how it stores SMS is up to the system integrator
Aug 13 02:29:15 <yang_office> How the history plugin work with oFono?
Aug 13 02:30:24 <yang_office> via D-Bus APIs?
Aug 13 02:32:13 <yang_office> Or something like plugins/example_history.c?
Aug 13 02:38:02 <denkenz> that is up to the system integrator ;)
Aug 13 02:39:15 <yang_office> If it's like the example_history.c, would the code be checked into oFono tree?
Aug 13 02:40:05 <yang_office> Thus oFono would have platform related code. Is this allowed?
Aug 13 02:41:10 <yang_office> And this also implies D-Bus API and plugin have the same capability to store all the information related to sms, right?
Aug 13 02:41:33 <denkenz> I think you're jumping to conclusions :)
Aug 13 02:41:44 <denkenz> What do you really want to know?
Aug 13 02:42:11 <yang_office> WR want to store their sms, and they are asking which would be a solution.
Aug 13 02:42:32 <denkenz> WR can provide their own SMS history plugin
Aug 13 02:42:44 <denkenz> They can either submit it upstream to us, or maintain it themselves
Aug 13 02:43:28 <yang_office> Could the plugin be not open source?
Aug 13 02:43:42 <denkenz> The plugin has to be open source
Aug 13 02:43:53 <denkenz> We're GPL v2 for a reason
Aug 13 02:44:13 <yang_office> I see.
Aug 13 02:45:01 <yang_office> So oFono would include platform specific code:)
Aug 13 02:45:24 <denkenz> oFono already includes platform specific code, e.g. isi, mbm, huawei, etc
Aug 13 02:45:52 <yang_office> But that's modem specific, not OS specific. 
Aug 13 02:46:15 <yang_office> oFono needs to handle all kinds of modem, surely it will code with different modems
Aug 13 02:46:21 <denkenz> Shrug, platform specific too
Aug 13 02:46:35 <denkenz> e.g. see calypso modem driver, its only really for the Freerunner
Aug 13 02:47:36 <yang_office> Oh, yes. It's already OS specific.
Aug 13 02:48:28 <yang_office> Another question is about MMS. Do you know Ben's work on MMS is a standalone middleware or a plugin inside QMF?
Aug 13 02:50:36 <yang_office> Will MMS be another daemon similar to oFono, or we can make it work as a plugin in QMF.
Aug 13 02:50:46 <denkenz> it will end up being a separate daemon
Aug 13 02:52:00 <yang_office> So Ben is working on such a daemon?
Aug 13 02:52:24 <denkenz> I think so
Aug 13 02:53:38 <yang_office> Thanks a lot for the answer. By the way, do you have comments on my EFust/EFest reading patch?
Aug 13 02:55:24 <denkenz> No not yet, swamped
Aug 13 02:55:56 <yang_office> That's fine.
**** ENDING LOGGING AT Fri Aug 13 02:59:57 2010